We're not talking full HTML documents here, just strings with an occasional link or word styling or maybe once in a while a bulleted list. But your experience differs from mine then.
Regarding the link, I was more thinking about how your system handles the some.introductory.paragraph translation and how you differentiate between potential HTML in the translation vs HTML in the click_here variable vs HTML in another potential variable containing user input.
My experience is that most translators actually do know basic HTML or can at least translate an english base string containing HTML into their own language without messing it up. CSS would of course not be present, just sematic HTML (or any other kind of "rich text" -- it wouldn't have to be HTML specifically).
I'd argue that one reason rich text translations are rare is because it's such a pain. Just look at any static documentation web site -- styling and links are everywhere. Of course I want that for non-static web sites/apps as well; links to navigate the app, side-bars or popovers with help text and documentation, more links, bulleted lists ...
I'm not sure I understand how your example prevents that HTML threat model you mention, unless the "link" function generates some kinds of magic placeholders that you then replace with HTML in another step you did not mention. If "link" generates an A tag, then you're already trusting the translation with HTML powers anyway (not that I find that much of a problem -- at least not with my approach where XSS via params is not possible).
1. Usually OSS projects accept patches via PRs. Translations are no different for 99% of all projects.
2. Why? Keys with params will break no matter if it is in MessageFormat or TypeScript. At least with TypeScript you will know something is wrong and can comment out the problematic key in question.
3. And that is great! Bugs should break builds.
4. Well, that could happen. But you could also structure your localizations into a stand-alone subproject and then it would no longer be the case.
Well that's the point. It's not anything new at all, just the plain JavaScript/TypeScript/TSX you already use. No extra tools are required either; TypeScript and a good editor like VS Code handles it all.
So let me just first say that just sending a CSV/JSON/YAML/whatever file to professional translators and expect good results back is just not going to work. We've done that and sometimes the context is just horribly wrong. The only way to get good results is for the translators to actually see the UI or even better run the app themselves.
But I'm interested to hear how you would solve the presentation issues you mention. I absolutely think the right way is to have translations be HTML fragments. How else would you know what part of the sentence should be italic or contain a hyperlink?
That's MessageFormat and I think its a pain and severely limited. Maybe it's OK for English, which has really simple grammatical rules, but just add some gender to your plurals and it starts to become very complicated very quick.
Building complex sentences absolutely require some form of logic. Different languages have very different rules for gender, plural, sexus, classes ( animated/humane/plants/etc).
I'm arguing that each implemented language in a program should be able to define its own set of utility functions that makes sense for that particular language.
Also, since translations as code can return both plain strings and (for example) HTML fragments, security is instead increased, because encoding/decoding would no longer be an issue.
That Perl reference was new to me. Very interesting. Never localized my Perl programs back in the day. But of course I should not be surprised that Perl had a solution to any given problem 20+ years ago ...
I like Fluent. It's just that ... when all the power of modern JavaScript/TypeScript (template literals/JSX/validation/custom functions) and code editors (syntax highlighting/JSDoc/references/usages) are already in place, why not use it instead of introducing a whole new layer of tooling?
Well. For small projects or even larger open source projects I would expect the translators to just clone a ts file (which would basically just be JSON, but with comments, template strings, function calls), change the translations and contribute the file as-is.
For large projects it would still be possible to have a utility program export a translation to CSV/whatever and re-create a ts file from it when it comes back.
Any mistakes made by the translator would immediately show up when building the program or just visiting the file in a code editor.
Yeah, naming each translation with a key is definitely the way to go. Apps are full of buttons and labels and short sentences so context is absolutely necessary.
Well, you have to start somewhere. Anyone can learn how to call a function, just like they can learn MessageFormat. And basic HTML is something translators must already know.
Anyone can learn how to call a function, just like they can learn how to splice a parameter into a string. And translators already have to know basic HTML anyway.
MessageFormat is code. It's just not a very powerful language. And it knows nothing about rich text, just plain strings, which means that you have to deal with manual HTML decoding in the application, ensure all translations are actually producing valid HTML and absolutely not forget to encode all string params that could be user input.
Using tagged template literals and JSX in the translations avoids all those problems.
Making localized web apps is such a pain and too often an afterthought. But what if it took almost no extra effort to make the app localized from the start?
What if you could get static type checking, key documentation and code completion right in VS Code?
And what if the translations could be generated using an actual programming language, and even represent HTML markup and not just plain strings?
Unfortunately, unless you have a very deep understandning of your operating system AND you're logging audit to a REMOTE system, you should assume the worst and reinstall all reachable systems from scratch. Invalidate all ssh keys. Then check your databases for suspicious admin accounts before going live.
If not, how do you know if backdoors were installed, if the databases were modified, if local (known or unknown) exploits were used to gain root or if private ssh keys were stolen or used to gain access to other servers?
Regarding the link, I was more thinking about how your system handles the some.introductory.paragraph translation and how you differentiate between potential HTML in the translation vs HTML in the click_here variable vs HTML in another potential variable containing user input.