Please note that the word 'Computer' is changed to 'Device' for mobile/locales/en-US/chrome/browser.properties
nhirata_bz
locales/en-US/chrome/browser.properties.
This has to do with the Bug 654733 ( https://bugzilla.mozilla.org/show_bug.cgi?id=654733
). The change set is in : http://hg.mozilla.org/mozilla-central/rev/8d0ca70728ff
and the file affected is : mobile/locales/en-US/chrome/
browser.properties
Regards,
Naoki Hirata
flod
> Please note that the word 'Computer' is changed to 'Device' for mobile/
> locales/en-US/chrome/browser.properties.
punctuation, you're changing a word for consistency with other strings.
IMO this requires a new entity so that all people can't miss this change.
Francesco
flod
> Not sure this is the right way to go: you're not fixing a typo or
> punctuation, you're changing a word for consistency with other strings.
instead of "device" in /overrides/netError.dtd and
/overrides/passwordmgr.properties
Francesco
Axel Hecht
This is not the right way to go, as flod hinted at.
I've reopened the bug, and I'll back the patch out on Monday if it's not
otherwise fixed by then. Don't have time to do that this weekend.
Axel
Wesley Johnston
We're not changing for consistency. We're changing because the
original string was copied from Firefox, and wasn't updated so that it
"made sense" in Fennec.
I'm sure this has been debated before, but this just feels like a hole
in our l10s toolchain to me. Localizers should see when we change a
string and have the chance to update theirs if need be. Having to add
an entire new entity with a meaningless number stuck on the end just
so that localizers are notified seems a bit absurd.
Toni Hermoso Pulido
Hello Wesley,
you have a point. It seems to me absurd as well from a programmer POV,
but defining a new entity (often simply by adding a number to the name),
and removing the previous one, is the only real practical way localizers
have to notice any change.*
We basically depend on https://developer.mozilla.org/en/compare-locales
for this.
Unless we can learn it from another way, and a new system can be
designed for this (l10n-drivers may be thinking about), I would beg you
to stick to that convention.
Thanks,
* Letting apart intermediary conversions to Gettext some localizers do.
--
Toni Hermoso Pulido
http://www.cau.cat
Ricardo Palomares Martínez
> Al 14/05/11 16:39, En/na Wesley Johnston ha escrit:
>> in our l10s toolchain to me. Localizers should see when we change a
>> string and have the chance to update theirs if need be. Having to add
>> an entire new entity with a meaningless number stuck on the end just
>> so that localizers are notified seems a bit absurd.
>
> but defining a new entity (often simply by adding a number to the name),
> and removing the previous one, is the only real practical way localizers
> have to notice any change.*
I understand the reasons to mandate a change in the name of the
entity/key, and I think it *could* be done other way
(MozillaTranslator does it, as it detects changes comparing an
internally recorded last value for en-US against the current value in
the Mercurial working directory).
Anyway, I just wanted to ask you (and the rest of developers), if you
need to change the name of the label entity, to please change also the
name of corresponding commandkey and accesskey entities, so L10n tools
can bind the three properly. Even funnier you thought, don't you
think? :-) Fortunately, it is not the case with xpinstallPromptWarning.
Ricardo
Axel Hecht
Well, are you going to get a great global product without investing in
to it in every step of development?
No.
Changing the entity name is your investment in telling the tools and the
l10n community if a change that you make to a string requires to be
picked up by localizers or not. You're making that call once in a
central place, instead of making it 100 times around the globe. (Counter
example is a grammar bug, or a typo)
Axel