Thanks for reminding me about it.
So, I didn't think too much about it. I still see people using it and I think
that there are good reasons for them to prefer that "polymorphism" over what
you are suggesting. Here's my devils advocate hat:
> - avoid direct manipulation of textContent (because it requires manual
retranslations),
When they want to use l10nObject.raw, that's because the content is *not*
supposed to be retranslated. Think, song names.
> - avoid direct manipulation of innerHTML (because it's not safe),
Same here. Yeah, it is less safe, and they have to secure it themselves, but
they want it in the scenario where they don't want the content to be localized.
> - give more control to the localizer (don't bypass the localization layer
and insert the text yourself), and
The thing is, I don't believe it should always go through the localizer.
Let's revisit the song list example in Music app. The developer wants to
display an UI with a list of songs. He has a data base with those songs.
He wants to just loop over those songs and add them to UI, but he knows that
some songs have no title. In that case, he wants to localize the title HTML
element with l10nId "unknownTitle".
Or another example, where 99% of elements will have raw strings, and just 1%
will be localized - displaying a contact name in a contacts list UI. Every once
in a while that number is a voice mail. And we want to localize the node in
that case using "voicemail" l10nId.
The problem I see with your proposal is that you are requiring developers to
produce a significant number of strings that localizers will most likely never
want to touch. And if they touch them, they'll most likely will break them.
I don't know of any localizability problem that would be resolved by letting
localizers operate on such `songTitle` string, but I do believe that adding
more strings to resources, that are not going to be localized by anyone, is a
design mistake.
So, while I always thought that the if(translatable){}else{} pattern could be
replaced by what you suggested, and I even documented it in our docs stating
that devs can choose either way to go about it, I can see why they prefer the
if/else approach.
On top of that, there's one more issue which is performance. In principle, the
difference between if/else and "everything goes through l10n" can be described
as a difference between 0 CPU/mem cost, and pushing this string through
hundreds of lines of code, including string search, variable resolving,
concatenation, surrounding with FSI/PDI marks and in the end, we just put it
into textContent anyway.
If there's any reason to believe that this UI would work better in some locales
if we went for entity-with-variable approach, I'm all for it. But so far, I
haven't encounter a single case, and I've been refactoring a lot of our apps.
So, while the principle of "everything goes through l10n" appeals to me, the
pragmatic perspective suggests that this case is in fact a duality between a
localizable couple elements with "unknownTitle" and hundreds of elements with
raw strings should not result in hundreds of resolved entities that get
retranslated on language changes.
This brings my to my point. We can leave it "open", or we can help people write
what they want in a more regulated manner that also, as a benefit, will make it
easier for us to switch them if we eventually decide that yours, or yet
another, approach is better (I can imagine equivalent of plural form for
undefined variable).
zb.
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
