Missing files and extra properties in locale
armenzg
Do we have a tool that will copy the missing files for me so I can
just spend time translating the recently copied files?
Is there a tool that will remove the entities that compare-locales
marks as "-"?
Axel Hecht
compare-locales currently only hacks those in, translate toolkit doesn't
offer the full flexibility either.
I'm having thoughts on this for something based on Gandalf's lib. That's
gonna be easier as it's working closely on the source, but it'll require
some code and thinking.
Axel
F Wolff
> armenzg wrote:
> > The armenian localization has missing files that have to be added.
> >
> > Do we have a tool that will copy the missing files for me so I can
> > just spend time translating the recently copied files?
> >
> > Is there a tool that will remove the entities that compare-locales
> > marks as "-"?
>
> compare-locales currently only hacks those in, translate toolkit
> doesn't
> offer the full flexibility either.
What exactly do the "-" lines mean? If it indicates entities in the
translations that should be removed, I'm quite sure that the translate
toolkit will remove them as required.
Armen, I assume your current translations are not in PO format, but
either way, you might be interested in these pages:
http://translate.sourceforge.net/wiki/toolkit/moz2po
http://translate.sourceforge.net/wiki/toolkit/migrating_to_firefox
The last page is just an example of a fairly involved migration (from
the old Mozilla suite to Firefox 1.0). Your case should be simpler of
course, but many of the same issues apply.
Some of the advantages of using this in your case is that the files will
all be put into place, it will try to detect moved files, it will try to
pre-translate as much as possible from a translation memory, and you can
do pocount on the PO files to see exactly how much work is left. The
Mozilla files generated from those incomplete files will contain all the
already finished work, and the rest in English. You can then continue
with the PO files, but obviously you wouldn't need to.
Keep well
Friedel
Axel Hecht
One caveat on translate toolkit here, as the tool uses the en-US sources
to fill in the localized strings it's ending up with the en-US license
header. This isn't much of a problem for original contributions, as it's
up to your discretion to add yourself to the license header or not, but
for modifications of existing work by others, removing them from the
license header is not good.
Axel
Zbigniew Braniecki
With silme you can do:
./scripts/l10nmerge.py ./path/to/en-us ./path/to/armenian
./path/for/result -t [1,2,3]
where:
-t 1: en-us files will be used with armenian entity values where possible
-t 2: armenian files will be used with missing entities added at the end
-t 3: armenian files will be used with missing entities added in the
places where they are in en-us.
Should help :)
greetings
Zbigniew Braniecki
--
Mozilla (http://www.mozilla.org)
Jeferson Hultmann
On Sun, Aug 3, 2008 at 3:15 AM, armenzg <arm...@gmail.com> wrote:
>
> Do we have a tool that will copy the missing files for me so I can
> just spend time translating the recently copied files?
>
> Is there a tool that will remove the entities that compare-locales
> marks as "-"?
Are you translating "by hand"? I think you should consider using
Mozilla Translator to manage your translations.
Regards,
Jeferson Hultmann
<zbran...@mozilla.com> wrote:
> With silme you can do:
>
> ./scripts/l10nmerge.py ./path/to/en-us ./path/to/armenian
> ./path/for/result -t [1,2,3]
>
> where:
> -t 1: en-us files will be used with armenian entity values where possible
> -t 2: armenian files will be used with missing entities added at the end
> -t 3: armenian files will be used with missing entities added in the
> places where they are in en-us.
The problem is when en-US values change. This approach would keep
outdated translations (e.g. about:mozilla).
--
Jeferson
Axel Hecht
about:mozilla is really a bug, i.e., this should never happen.
The opposite case is when a typo get's corrected in en-US, or they move
from ... to …, at which point the po-approach falls back to
English for no good reason.
Axel
armenzg
> The problem is when en-US values change. This approach would keep
> outdated translations (e.g. about:mozilla).
>
> --
> Jeferson
Jeferson Hultmann
A wrong translation due to an en-US change.
Example:
Fx2 en-US
MUI_TEXT_STARTMENU_SUBTITLE=Choose a Start Menu folder for the
$(^NameDA) shortcuts.
Fx2 pt-BR
MUI_TEXT_STARTMENU_SUBTITLE=Selecione a pasta do menu Iniciar para os
atalhos do $(^NameDA).
Fx3 en-US:
MUI_TEXT_STARTMENU_SUBTITLE=Choose a Start Menu folder for the
$BrandFullNameDA shortcuts.
Fx3 pt-BR (outdated)
MUI_TEXT_STARTMENU_SUBTITLE=Selecione a pasta do menu Iniciar para os
atalhos do $(^NameDA).
If you use a tool like Mozilla Translator the change will be detected
(you will be asked you to provide a new translation).
--
Jeferson
João Miguel Neves
>
> Example:
>
> Fx2 en-US
> MUI_TEXT_STARTMENU_SUBTITLE=Choose a Start Menu folder for the
> $(^NameDA) shortcuts.
> Fx2 pt-BR
> MUI_TEXT_STARTMENU_SUBTITLE=Selecione a pasta do menu Iniciar para os
> atalhos do $(^NameDA).
>
> Fx3 en-US:
> MUI_TEXT_STARTMENU_SUBTITLE=Choose a Start Menu folder for the
> $BrandFullNameDA shortcuts.
> Fx3 pt-BR (outdated)
> MUI_TEXT_STARTMENU_SUBTITLE=Selecione a pasta do menu Iniciar para os
> atalhos do $(^NameDA).
>
>
> If you use a tool like Mozilla Translator the change will be detected
> (you will be asked you to provide a new translation)
he should:
1) if it's a typo, change the string
2) otherwise, change both the string and the key
Axel, are programmers really aware of this? Seems like we're having some
distractions lately.
Best regards,
João Miguel Neves
Axel Hecht
In this particular case, rstrong has added an additional test to the
makefile to check for the variables. Note that the string didn't really
change, just the name of the variable.
It's one of those edge cases that make l10n fun.
Axel
Zbigniew Braniecki
Right. Command-line tools are not made for in-live translations, rather
for one time state changing.
What I can do is adding to l10nmerge ability to ignore strings after
given comment (in type 2) in order to avoid such problem.
But in reality, if someone is localizing alive when en-US changes, he
should be using high-level tools instead of comman-line ones.
And high-level tools are just slowly appearing - verbatim, mozilla
translator, narro, pootle etc.
Greetings
Axel Hecht
Command line tools can still be interactive, I'm pondering whether it'd
make sense to have something like a l10n shell to cd to subdirs for
compare-locales output and to possible call merge for particular files.
I could picture a session like
l10n-shell foo/browser/locales/l10n.ini l10n-base de
> cd b[TAB]
cd browser/chrome/browser
> ls
browser.dtd -1/+0
> diff b[TAB]
diff browser.dtd
browser.dtd
-someEntity.label
> merge browser.dtd
... adding someEntity.label to browser.dtd
> ^D
and then you could head over to browser.dtd and edit. You could update
your compare-locales result without leaving the shell, too.
The other alternative would be an extension to komodo, as that's able to
run python, and display UI on all our platforms.
If it's thought through a bit, there's likely a good chunk of code to
share between the two, so it wouldn't necessarily be either or.
Axel
João Miguel Neves
if we use the english string to translate.
Ricardo Palomares Martínez
>
> The problem is when en-US values change. This approach would keep
> outdated translations (e.g. about:mozilla).
Just for the record, MozillaTranslator catches these changes, marking
as Fuzzy while keeping the existing translation.
Ricardo.