alt Hacker NewsYeah, we've noticed that companies in the early stage ignore i10n completely and then eventually realize it's going to be a huge lift to retroactively support it
So, for the build time translation-
Yeah, I would say it's not reliable yet =p
But, it's not that far off. It's not magic- the idea is that we inject the t functions at build time so that they don't need to be in your code. The vscode extension is a good visual for this- for many patterns, it correctly notices what does or doesn't need to be translated.
But, the real problem is that if a process like this goes awry (a strange pattern leads to text being erroneously translated/untranslated) then it is next to impossible for someone to debug.
Glad you think this is cool. We think this is absolutely on the horizon, and we hope to be the first to get people using it... but in the meantime, we don't want to be responsible for issues on prod...
Replies
On this, I just want to share my take-away from my translation engineering days: I fully believe the "right way to do it" is to have two string types: A regular string type and a "user-visible string" type, in a similar way that some frameworks expose a "safe string" vs "unsafe string" (for escaping purposes).
User-visible strings are consistently translatable, and the translation mechanism needs to have deep access in the language for this. I think in typescript this is a fairly doable thing given the AST access you yourself make use of. I'll gladly dig into how you do this on your end but I'm guessing it's somewhere along those lines but not quite?
Incidentally, when you have two string types, it becomes fairly straightforward to detect strings that probably should be translated but aren't tagged as such. Most strings are like this, in fact, because string constants tend to be a bad idea in general (vs numeric constants), and string operations tend to be a bad idea in the context of i18n (you want to use templated strings instead). So you tag until you only have a few left-over.
> companies in the early stage ignore i10n completely and then eventually realize it's going to be a huge lift to retroactively support it
That's the correct thing to do. When you're first building a product you're trying to prove that it can and should exist: that you can get people to pay you money for it. It doesn't make sense to spend your time or money doing anything else.
Once you're successful then you know that people in one country like your product and maybe people in another company will as well. But until you know that, that's the only thing you should be working on.