[Resending, as I mistakenlly sent it just to Zibi]
El 29/08/15 a las 05:35, Zibi Braniecki escribió:
> On Wednesday, August 26, 2015 at 12:18:46 PM UTC-7, Robert Kaiser wrote:
>> Now, either we have tools that alert localizers of changes that may be
>> interesting to them to react to (if en-US makes the "zero" case better,
>> a number of other localizations might want to do the same) or we
>> probably still need to follow a similar rule set.
>
> That's precisely the trap that I'm trying to avoid. "Maybe locales will want to improve their translations when they see that en-US improves" is a fallacy in the world where we break 1-1 matching.
This is a pretty interesting problem. I plan to support L20n some time
in the future in the tool I'm writing to replace MozillaTranslator,
and the whole break of 1:1 relation between, not IDs, but indexes,
requires that tools check every string in the whole translation file
set for ID+index combinations used as variables, and then look up the
ID to see if the index is defined.
If you change the ID in en-US (which, Zibi, can't be disregarded as
the reference for localizers), then you may be forcing localizers to
change A LOT of different strings, not just the ID-changed L20n object
itself. Do that in a shared (dom, netwerk, security, toolkit) module
and you're requiring to review the entire translation.
In contrast, if the tool is able to "see" that an en-US string content
has changed, it can present it to the localizer, and he/she will be
able to decide if that involves deeper changes in the localized ID and
their usages across the whole translation.
> It's almost like saying "we should alert localizers when german
> version of that string changes, because maybe german localizers
> fine tuned it in a way that others might want to copy".
It is not the same, because the German version is tuning just for
their own language. en-US "tune" may or may not have an impact in the
rest of localizations; it even could have an impact in some of them
while not being relevant for others.
> I believe we should not. Neither for de, nor for en-US. I asking to
> deprioritize en-US and stop assuming that every typo en-US has will
> be followed to the letter by localizers, because it shouldn't.
Unless you find a way to get tools to distinguish if a change in the
en-US strings are due to a typo or to a semantic change, you can't
"deprioritize" en-US, because that's what all localizations follow.
en-US IS the reference to the rest of localizations.
But I'm not contradicting myself. en-US shouldn't change IDs even for
semantic changes, but tools (and that includes L10n dashboard in the
first place) must be able to catch string changes, added and removed
indexes and custom data, etc., and warn localizers about such changes,
all of those without having to change the ID.
JM2C
--
Proyecto NAVE
Mozilla Localization Project, es-ES Team
http://www.proyectonave.es/
Diaspora:
rick...@diasp.eu