this post was submitted on 11 Aug 2024
210 points (97.7% liked)

Lemmy Apps

4992 readers
1 users here now

A home for discussion of Lemmy apps and tools for all platforms.

RULES:


An extensive list of Lemmy apps is available here:

LemmyApps.com

or lemmyapps.netlify.app


Visit our partner Communities!

Lemmy Plugins and Userscripts is a great place to enhance the Lemmy browsing experience. [email protected]

Lemmy Integrations is a community about all integrations with the lemmy API. Bots, Scripts, New Apps, etc. [email protected]

Lemmy Bots and Tools is a place to discuss and show off bots, tools, front ends, etc. you’re making that relate to lemmy. [email protected]

Lemmy App Development is a place for Lemmy builders to chat about building apps, clients, tools and bots for the Lemmy platform. [email protected]

founded 1 year ago
MODERATORS
 

This is applicable to almost any piece of software with text in it. When starting your new app, you should make sure you are using a separate language file for the strings in your app. This makes text reusable, and you can change it all in one place.

Once your app gains a community, if you did this, you can also get translators!

With Photon i made the massive mistake of hardcoding everything up until the app became massive, and my PR for un-hardcoding all the strings looks like this:

The amount of lines modified in the GitHub PR. 2,067 lines added, 1,082 removed.

It was worth it though! Because the community has translated it into 11 languages!

top 22 comments
sorted by: hot top controversial new old
[–] [email protected] 32 points 3 months ago (1 children)

Alternative interpretation cause i find i18n extremely boring and hate the indirection it adds to a code base : you're telling me I can start making an app without this hassle, and it will only cost me a 2Kloc PR some time in the future. That's a totally manageable price to pay and makes the early dev experience much better (which can have a lot of impact on momentum).

[–] [email protected] 2 points 3 months ago* (last edited 3 months ago) (1 children)

Also: shouldn't the process of searching and replacing strings be quite easy to automate?

Edit to clarify: I meant searching and replacing hard-coded strings into whatever library handles translateable strings. Not hard-coding different languages.

[–] [email protected] 1 points 3 months ago (1 children)

Not necessarily. You have to be able to tell between language strings vs strings that are supposed to be hardcoded

[–] [email protected] 1 points 3 months ago

Ok, that's fair. I'd probably add a # FIXXME flag when I don't want to mess around with that stuff for the moment to do that.

[–] [email protected] 20 points 3 months ago

Fantastic recommendation.

[–] [email protected] 15 points 3 months ago

There's two approaches you can use here.

You can use a list of strings used in the app and have each string only occur once. Then using translation files you can translate each of those strings into another language.

This usually works fine, but has the downside of losing the context of a string. Context can matter a lot when translating, you often see this when the wrong translation is used, which is a correct translation but not for the context it's in. It can also be tricky when two strings are the same not by definition, but by chance. When in another language those strings should not be the same, this can't be resolved easily.

So for situations where a better translation is required another approach is used. Instead of strings directly, placeholders are used. These placeholders should be structured in such a way, the context is obvious and people could find where it's used easily. These placeholders are also unique, where two strings that are the same by chance don't use the same placeholder. Then for each language, including the "primary" language, a translation file is used. That translation file translates the placeholders into the correct string. For translating the translator uses the placeholders and the primary language file to translate the strings. Good tools for this exist that allow the same strings to be translated once, but show the context so the translator can decide to use different translations for the same string in a different context.

Using the placeholder approach is a bit more work and adds some overhead, but I've seen it used to produce awesome results. It prevents the pitfalls of the simpler approach.

[–] [email protected] 14 points 3 months ago (1 children)

How do you deal with the fear that contribution in languages you don't know could be malicious/offensive? This is something that would scare me when reviewing contributions adding new languages

[–] [email protected] 4 points 3 months ago

From another project I've contributed as translator, not as dev:. They had set up a completely different flow, translation tool, bug reporting, deployment, etc. The dev had basically nothing to do with it,except forwarding bug reports.

The tool landscape grew quite a bit in the last decade though, I think - pretty sure you can do the pull request / review between volunteers as well by now without issues. M

[–] [email protected] 7 points 3 months ago (2 children)

I'm French, so when building any GUI stuff I just tend to start from the beginning with both French and English languages, that way I have a reason for doing this from the start. I'm thinking I should also add Spanish, so that I can keep my admetedly low skills in Spanish.

[–] [email protected] 11 points 3 months ago (1 children)

german is also a good one for discovering that long words break your UX :)

[–] [email protected] 5 points 3 months ago (1 children)

Unfortunately this is an issue for anyone visually impaired.

People just do not stop to think how difficult their UX is if people need very large fonts.

[–] [email protected] 4 points 3 months ago (1 children)

how difficult their UX is if people need very large fonts

What issue

s could th

at possibl

y cause?

[–] [email protected] 1 points 3 months ago (1 children)

The issue that layout containers are often unable to display large fonts on the widgets when certain restrictions are enforced in the layout. So, without giving time to try very large fonts. To Many developers never discover their applications just cannot be read by visually impaired people.

[–] [email protected] 2 points 3 months ago

yeah if the UI library is not ready to flow text and UI elements (including wrapping/breaking sensibly) then important information and interactive elements are inevitably clipped/unusable or jumbled beyond recognition

[–] [email protected] 3 points 3 months ago

Feel free to join the small [email protected] for Spanish content

[–] [email protected] 5 points 3 months ago* (last edited 3 months ago) (3 children)

Is it really more effort to just extract relevant strings later, rather than worrying about it the whole time? Asking beyond lemmy apps too.

[–] [email protected] 7 points 3 months ago

Once you have this set up, you won't worry about it again. It will just become "the way it is done". And it's just the correct way to build software IMHO, even if you have no plans right now to offer multiple languages.

[–] [email protected] 4 points 3 months ago

Extrapolation takes quite a while, and there are other benefits to having a language file, like reusability.

[–] [email protected] 2 points 3 months ago

for things like translation it is obviously required, but it will be ongoing as the app changes over the years

so it's just about realising that text in the UI is just another kind of content that has to be managed so there will need to be infrastructure and process to make that easier

[–] [email protected] 5 points 3 months ago

You've inspired me to contribute to translating your app into a new language!

[–] [email protected] 5 points 3 months ago

I hear ya! My only pain point is structuring that colossal json file. 😅

[–] [email protected] 2 points 3 months ago

We use I18n at work and it’s great. It’s a bit more cumbersome to write strings but then again I could write a key mapping for that I guess.