Hacker News Reader

Comment by iLoveOncall | Hacker News Reader

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.

View on HN

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.

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.

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.

> 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.

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>

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?

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.

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)

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.

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.

> 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 > </.

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?

Agreed. I don’t really know what problem these i18n tools solve that this doesn’t.

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.

Reply on news.ycombinator.com