5 ms·

I haven't worked with a lot of i18n systems, but on the contrary I have found them to be a huge amount of work. I have used the Angular one and the Laravel one

I haven't worked with a lot of i18n systems, but on the contrary I have found them to be a huge amount of work. I have used the Angular one and the Laravel one, and both are a chore to use, because they interrupt your flow. If I'm writing the view of my component, I don't want to have to switch to another file, think of a key that identifies that text well enough and then translate the text, thinking of potential plurals and others. I just want to write my damn text. I'd rather spend days doing the mind-numbing work when needed rather than slow down my development process and remove all enjoyment from it ad vitam aeternam because of i18n-ing on the fly.

BlargMcLarg 4y ago
On the other side we have the individuals inheriting such codebases and being told to add multilingualism when a bunch of other soft dependencies and assumptions exist which make this entire thing a disaster to implement. It is fairly small and trivial to add so please, if you foresee an event where systems have to support multiple languages and odds are you won't work on it yourself, prepare the damn codebase for it.
matsemann 4y ago
You don't need to bake in a complete i18n solution, though. Just create a simple map of keys->strings, and then a function ala getStringForKey(key, language) { return map[key] and then whenever you actually need it, just expand on it. But at least you then have all strings in one place, and a common way of accessing them. (And easy lookup of all places using these strings)
- sonthonax 4y ago
  Agreed. I don’t really know what problem these i18n tools solve that this doesn’t.
  - matsemann 4y ago
    But if you end up in a situation where i18n tools are needed, this function can be the single entry point anyways, abstracting most of it away.
- iLoveOncall 4y ago
  Your function doesn't solve any of the issues I mentioned, you still need to switch to another file, still need to think of a sufficiently explicit key, still need to handle plurals and masculine / feminine variations, etc.
  - matsemann 4y ago
    YAGNI ;) You can skip all those things the first time. You don't need to have a separate file or anything. Just have a stupid function returning its input or whatever. The important part is having an entry-point, and an easy way to find all relevant uses in the future. You could then later, when i18n is needed, write a script finding those usages and automatically extract them. That's what I've done once before. And it was a thousand times easier than the time before where we had to hunt through all of frontend, backend, cms etc. to find stuff.
    - iLoveOncall 4y ago
      > The important part is having an entry-point, and an easy way to find all relevant uses in the future. You already have it, it's everything that's in between {{ }} and > </.
      - matsemann 4y ago
        Do you want to translate numbers between ><? What about alt-texts not in those tags? Things passed as props multiple layers? What about strings coming from backend? Do you read some things from the environment?
samuelstros 4y ago
I might have something for you that reduces context switching. I am working on an IDE extension that shows the content of a localized message inline. A screenshot can be found here https://github.com/inlang/inlang#vs-code-extension https://github.com/inlang/inlang#vs-code-extension.
healsjnr1 4y ago
These patterns and practicee generally aren't intend for _you_ as the developer of the app right now. They are intended for the poor shmuck 18 months later who has to work with a tangled mess of copy text stored in JS, server side yaml files and a CMS. I've been that person at least 3-4 time now. I've waded through changes where having static strings got the UI would have simplified things immensely, and _none_ of these have had anything to do with internationalisation. They have been far more prosiac (Legal request, product changes, rebranding, just general things like "where did this text under interest rate calculator come") but have still taken significantly longer than they should have. When you are writing these apps it can feel like it's not that hard to go back later and pull out strings, just some grunt work. But once you munge your code through three refactors and a framework change it becomes so much harder.
Izkata 4y ago
> I have used the Angular one and the Laravel one, and both are a chore to use, because they interrupt your flow. If I'm writing the view of my component, I don't want to have to switch to another file, think of a key that identifies that text well enough and then translate the text, thinking of potential plurals and others. I just want to write my damn text. In django (python), the key is just the English text (with optional extra context), and if it doesn't find a translation for the target language it dumps that text back out. You don't need to go anywhere else until actually doing the translating.
- SebastianKra 4y ago
  Does this work well? What happens when you need to make a change in the english version? Do you just search/replace through all the translations? Does django do anything to make this easier, or does it work with any i18n library?
  - Izkata 4y ago
    There's also "translate to English", so you can instead treat it directly as a key and use that, or treat the English text as a key and change/add to the file if it's just something like a typo. Don't recall about the second, we only had translations on one site and it's been a few years.
- iLoveOncall 4y ago
  It does the same in one of the two that I mentioned (Angular I believe), but you still need to mark plurals and other stuff like that. Here is an example about a basic case that you will encounter multiple times per page: <span i18n="Pretty update timestamp|Update timestamp prettyfied accompanied by user gender@@prettyUpdateTimestamp">Updated: {minutes, plural, =0 {just now} =1 {one minute ago} other {{{minutes}} minutes ago by {gender, select, male {male} female {female} other {other}}}} </span>

BlargMcLarg 4y ago

On the other side we have the individuals inheriting such codebases and being told to add multilingualism when a bunch of other soft dependencies and assumptions exist which make this entire thing a disaster to implement. It is fairly small and trivial to add so please, if you foresee an event where systems have to support multiple languages and odds are you won't work on it yourself, prepare the damn codebase for it.

matsemann 4y ago

You don't need to bake in a complete i18n solution, though. Just create a simple map of keys->strings, and then a function ala getStringForKey(key, language) { return map[key] and then whenever you actually need it, just expand on it. But at least you then have all strings in one place, and a common way of accessing them. (And easy lookup of all places using these strings)

sonthonax 4y ago
Agreed. I don’t really know what problem these i18n tools solve that this doesn’t.
- matsemann 4y ago
  But if you end up in a situation where i18n tools are needed, this function can be the single entry point anyways, abstracting most of it away.
iLoveOncall 4y ago
Your function doesn't solve any of the issues I mentioned, you still need to switch to another file, still need to think of a sufficiently explicit key, still need to handle plurals and masculine / feminine variations, etc.
- matsemann 4y ago
  YAGNI ;) You can skip all those things the first time. You don't need to have a separate file or anything. Just have a stupid function returning its input or whatever. The important part is having an entry-point, and an easy way to find all relevant uses in the future. You could then later, when i18n is needed, write a script finding those usages and automatically extract them. That's what I've done once before. And it was a thousand times easier than the time before where we had to hunt through all of frontend, backend, cms etc. to find stuff.
  - iLoveOncall 4y ago
    > The important part is having an entry-point, and an easy way to find all relevant uses in the future. You already have it, it's everything that's in between {{ }} and > </.
    - matsemann 4y ago
      Do you want to translate numbers between ><? What about alt-texts not in those tags? Things passed as props multiple layers? What about strings coming from backend? Do you read some things from the environment?

samuelstros 4y ago

I might have something for you that reduces context switching. I am working on an IDE extension that shows the content of a localized message inline. A screenshot can be found here https://github.com/inlang/inlang#vs-code-extension https://github.com/inlang/inlang#vs-code-extension.

healsjnr1 4y ago

These patterns and practicee generally aren't intend for _you_ as the developer of the app right now. They are intended for the poor shmuck 18 months later who has to work with a tangled mess of copy text stored in JS, server side yaml files and a CMS. I've been that person at least 3-4 time now. I've waded through changes where having static strings got the UI would have simplified things immensely, and _none_ of these have had anything to do with internationalisation. They have been far more prosiac (Legal request, product changes, rebranding, just general things like "where did this text under interest rate calculator come") but have still taken significantly longer than they should have. When you are writing these apps it can feel like it's not that hard to go back later and pull out strings, just some grunt work. But once you munge your code through three refactors and a framework change it becomes so much harder.

Izkata 4y ago

> I have used the Angular one and the Laravel one, and both are a chore to use, because they interrupt your flow. If I'm writing the view of my component, I don't want to have to switch to another file, think of a key that identifies that text well enough and then translate the text, thinking of potential plurals and others. I just want to write my damn text. In django (python), the key is just the English text (with optional extra context), and if it doesn't find a translation for the target language it dumps that text back out. You don't need to go anywhere else until actually doing the translating.

SebastianKra 4y ago
Does this work well? What happens when you need to make a change in the english version? Do you just search/replace through all the translations? Does django do anything to make this easier, or does it work with any i18n library?
- Izkata 4y ago
  There's also "translate to English", so you can instead treat it directly as a key and use that, or treat the English text as a key and change/add to the file if it's just something like a typo. Don't recall about the second, we only had translations on one site and it's been a few years.
iLoveOncall 4y ago
It does the same in one of the two that I mentioned (Angular I believe), but you still need to mark plurals and other stuff like that. Here is an example about a basic case that you will encounter multiple times per page: <span i18n="Pretty update timestamp|Update timestamp prettyfied accompanied by user gender@@prettyUpdateTimestamp">Updated: {minutes, plural, =0 {just now} =1 {one minute ago} other {{{minutes}} minutes ago by {gender, select, male {male} female {female} other {other}}}} </span>