[ANNOUNCE] Call for Tool communities around fx4, desktop and mobile
Axel Hecht
as you've seen in my other post, we're ramping up on outreach around
Firefox 4. As we don't know all the tools, we'd like you to follow up
here with how to do the smart thing with your tools.
Might be good to reiterate on things like how to update the content on
web tools, export, intermediate files, etc.
Also, for non-webtools, which versions of the tools are current.
Thanks
Axel
Dwayne Bailey
really simple.
If you need help
================
* Ask in this thread, or
* Join us on IRC at irc.freenode.net #pootle
* If you want to host on Pootle I can do it for you
How to do it
============
1) Get the latest PO templates from here (thanks Rael):
http://hg.mozilla.org.tr/mozilla-central/mozilla-l10n/archive/tip.zip
I just downloaded mozilla-l10n-9ca557302b65.zip - the number might be
different for you.
2) Make sure you have the translate toolkit installed, get the latest
version from here:
http://sourceforge.net/projects/translate/files/Translate%
20Toolkit/1.8.0/
It is also packaged for most Linux distros. You don't need the very
latest, but it doesn't hurt.
3) Get your PO files ready. It helps if they are in version control
(make backups if they aren't).
4) We migrate your PO files from the old version to the new version
pomigrate2 --use-compendium --pot2po old-po new-po pot
<old-po> existing PO files for your locale
<new-po> new PO files that will be created for your locale
<pot> the PO templates you downloaded in 1) above in our case it is
mozilla-l10n-9ca557302b65/pot
5) We convert the PO files to .dtd and .properties
po2moz -t en-US new-po ab-CD
<en-US> the en-US dtd and properties files in our case it was
mozilla-l10n-9ca557302b65/en-US
<new-po> the PO files you got from pomigrate2
<ab-CD> dtd and properties files for your locale
6) To finish off:
* Commit your ab-CD files to l10n-central
* Start translating your 'new-po' PO files
> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
--
Dwayne Bailey
Associate Research Director +27 12 460 1095 (w)
Translate.org.za ANLoc +27 83 443 7114 (c)
Recent blog posts:
* Localizing Mac OS X strings files using open source PO editors
http://www.translate.org.za/blogs/dwayne/en/content/localizing-mac-os-x-strings-files-using-open-source-po-editors
* What's new in Virtaal 0.6.1
* Localisation: How we guess the target translation language in Virtaal
Firefox web browser in Afrikaans - http://af.www.mozilla.com/af/
African Network for Localisation (ANLoc) - http://africanlocalisation.net/
Axel Hecht
for those not allergic to hg, but not savvy to reverse engineer the url,
you can also get Rail's pots by doing
hg clone http://hg.mozilla.org.tr/mozilla-central/mozilla-l10n/
and then doing an
hg update -u
like you'd do elsewhere to get updates.
Axel
Axel Hecht
> Hi,
>
> for those not allergic to hg, but not savvy to reverse engineer the url,
> you can also get Rail's pots by doing
>
> hg clone http://hg.mozilla.org.tr/mozilla-central/mozilla-l10n/
>
> and then doing an
>
> hg update -u
Doh, make that
hg pull -u
Axel
Philippe
> Hi,
>
> for those not allergic to hg, but not savvy to reverse engineer the url,
> you can also get Rail's pots by doing
>
> hg clone http://hg.mozilla.org.tr/mozilla-central/mozilla-l10n/
>
Or
hg clone http://hg_trunk.frenchmozilla.fr/
witch is updated more often (ok, ok, not so much it seems :) )
For informations (and this is more important), the transvition
(glossary) is following
1.9.2 : http://www.frenchmozilla.fr/glossaire/
and the trunk : http://www.frenchmozilla.fr/glossaire/trunk/
The 1.9.2 branch will be replaced by the 1.9.3 as soon as it is branched.
I'll try also to be more intuitive on the url at this time.
Philippe
Ricardo Palomares Martínez
> Firefox 4. As we don't know all the tools, we'd like you to follow up
> here with how to do the smart thing with your tools.
>
> Might be good to reiterate on things like how to update the content on
> web tools, export, intermediate files, etc.
>
> Also, for non-webtools, which versions of the tools are current.
Current MT version is v5.25. Some info is available at:
https://wiki.mozilla.org/L10n:MozillaTranslator
Nowadays, MT uses "product" as a synonym for a base directory
containing L10n files (either en-US or ab-CD). So, unless you're using
French specially crafted repository, you will need several "MT
products" for any given Mozilla product. For instance, I'm in charge
of es-ES localization of shared components and I have four products
for that: dom, netwerk, security and toolkit.
That said, there are different scenarios and configurations, but the
most common one would be that you have one or more "MT products"
created pointing to your local working copy of 1.9.2 branch repositoty
and you want to reuse that work for mozilla-central (or 1.9.3). The
simplest way to do it would be:
0) Of course, hg clone mozilla-central (or mozilla1.9.3; from now on,
I will mention just mozilla-central) to your hard disk.
1) Create new MT products pointing to mozilla-central. Don't forget to
set the Export translation directory to your l10n-central/ab-CD local
working copy directory for that product.
2) Run File → Update Product for each one. This will "populate" the
new products with the files, keys and entities in mozilla-central.
3) Run Advanced → Migrate Product. This will copy the translation in
the old product to the new one where the key/entity in the old product
has an equivalent one in the new product (where "equivalent" means
same path and filename, same key/entity name and same original text).
4) Run Edit → View Fuzzy and sort the resulting table by the
Translated column. Then select all rows with a non-empty translation
(pretty much like you would do in a spreadsheet) and click the
"Unfuzzy" button. Close the window.
5) Run Edit → View Fuzzy and sort the resulting table by the Keep
original column. Then select all rows with the Keep original flag set
(pretty much like you would do in a spreadsheet) and click the
"Unfuzzy" button. Close the window.
6) The remaining Fuzzy strings are the ones to be translated. You can
use the Edit Phrase dialog and the Suggestions button (or [Alt]+[S]
shortcut) to reuse some more previous translations. For the time
being, you better avoid running Edit → Auto-translate, because it uses
a very simplistic approach to provide translations (namely, for a new
en-US string, the first existing en-US match is used to get the ab-CD
value for it and copy it as the new translation).
7) After finishing your work, or whenever you feel so, you can export
the product (Export → Export SCM-based Translation). You will have to
manually hg add the files (and keep in mind that searchplugin files
will be exported, even if they are not needed, so you will have to
either remove them, hg ignore them or not add them; enhancing this is
my TO-DO list).
I think this is all. :-) Feel free to contact me if you need so (use
rpmdisguise-otros at yahoo.es, the From address in this post is no
longer valid, I reaaaaally have to change settings in SM). :-)
Ricardo
Дамјан Георгиевски
> really simple.
>
> If you need help
> ================
> * Ask in this thread, or
> * Join us on IRC at irc.freenode.net #pootle
> * If you want to host on Pootle I can do it for you
We (macedonian locale) used moz2po/po2moz for the work in Fx4.
First we created .po files from the 3.6 translation and .pot files from
the 4.0 english sources. Since hg.frenchmozilla.fr was not uptodate at
that time, I had to download the whole mozilla-central tree, and then
copy the locale files in the same dir structure as the rest of the
locales.
We keep our .po files in a git repo, and there are 3-4 people helping
with the translation.
This went pretty much ok, but there are 2 problems with these tools:
1.
if you have unstranslated strings in your .po files po2moz will
substitute them with english strings. This means you can no longer use
compare-locales to see what your status is.
(I also tried to comment this out, but couldn't find it in the source
code)
2.
when the english source strings are updated, I need to recreate the .pot
files and then update the .po files (pomigrate2)
this step makes a lot of unneccesseary changes to the .po files and
pollutes my git history - the .po file headers for example.
--
дамјан ((( http://damjan.softver.org.mk/ )))
Today we create the legacy of tomorrow.
smo
Re problems 1 and 2: Starting always from the latest en-US material
(!) and propagating the existing translations through it avoids both
problems. Assuming of course that POTs themselves are not (and do not
get) polluted.
We use OmegaT (www.OmegaT.org) and do not suffer from those side
effects, as the memory resides outside the files actually getting
translated. Having a cake and eat it too, as in the case of PO files,
has its side effects.
Regards
smo
Dwayne Bailey
> > If you are translating Firefox with moz2po/Pootle updating to Fx4 is
> > really simple.
> >
> > If you need help
> > ================
> > * Ask in this thread, or
> > * Join us on IRC at irc.freenode.net #pootle
> > * If you want to host on Pootle I can do it for you
>
> We (macedonian locale) used moz2po/po2moz for the work in Fx4.
>
> First we created .po files from the 3.6 translation and .pot files from
> the 4.0 english sources. Since hg.frenchmozilla.fr was not uptodate at
> that time, I had to download the whole mozilla-central tree, and then
> copy the locale files in the same dir structure as the rest of the
> locales.
>
> We keep our .po files in a git repo, and there are 3-4 people helping
> with the translation.
>
> This went pretty much ok, but there are 2 problems with these tools:
>
> 1.
> if you have unstranslated strings in your .po files po2moz will
> substitute them with english strings. This means you can no longer use
> compare-locales to see what your status is.
>
> (I also tried to comment this out, but couldn't find it in the source
> code)
When working in PO your true count of progress is always the counts on
your po files. I use the dashboard as a guide and put pocount stats in
my commit messages for my own reference.
When we created po2moz we chose this behaviour on purpose, by doing this
we always produce 100% correct output, no broken anything. I wanted to
translate, not track down strange XML crashes.
However, I have looked at changing the behaviour to allow us to drop
untranslated entries. Properties is done see
http://bugs.locamotion.org/show_bug.cgi?id=1527 you need to run po2prop
for that as it won't run by default in po2moz. DTD is proving much more
difficult to do. You can track progress in
http://bugs.locamotion.org/show_bug.cgi?id=1718
Anyone who is desperate for this and can code in Python, feel free to
help me out with DTD.
> 2.
> when the english source strings are updated, I need to recreate the .pot
> files and then update the .po files (pomigrate2)
>
> this step makes a lot of unneccesseary changes to the .po files and
> pollutes my git history - the .po file headers for example.
I don't like the header behaviour either. For now I reverse those
changes using a diff and 'patch -R', but it's too much manual work.
I'm tracking this here:
http://bugs.locamotion.org/show_bug.cgi?id=1672
Which other changes are you seeing? We follow the Gettext layout for PO
so any other minor changes are probably out of our control.
Armen Zambrano Gasparnian
The Armenian localization team has been using Narro
(https://l10n.mozilla.org/narro/narro_project.php?l=hy-AM&p=14) and it
has worked well for us.
Contributors and reviewers use the web interface to suggest translations
and approve them.
Narro imports new en-US strings every day or two (not sure).
It also points to the L10n Dashboard results.
The working process is:
* Every few days I export the project
* I download the diff that is produced against my hg.m.o/l110n-c/hy-AM repo
* I apply it, I do some standard clean up and review the diff
** When I review it I look for booleans that should not be translated
** I use compare-locales to find the ERRORS (0.9 is awesome) if any
The problem with Narro is that I have to look on the web-interface to
find the ERRORS that I have discovered and it is not an easy task as I
have to either do a search or to navigate to the right file. Fix it and
then have to export it again.
I wish two things:
* beefier machine running Narro to navigate and searching faster
(exporting is good speed)
* compare-locales well integrated into Narro
** output of it to point to the text on Narro so no more searching is
needed!
* Narro should not offer certain texts to be translated if the
LOCALIZATION NOTES indicates not to.
Here is a blog post in the matter.
http://armenzg.blogspot.com/2010/10/how-we-use-narro-to-localize-firefox.html
Best regards,
Armen
Peter Pin-Guang Chen
We (zh-TW team) are using Narro, too, but with some differences.
It's too far to send each mouse click in Narro across the Pacific Ocean so
we decided to run it in our local server (http://translate.moztw.org/) as a
bridging service,
We currently have Narro 0.9.4 installed, there're also some scripts like
automatic hg pull, web compare-locales results, we also made a hierarchy ln
-s symlinks for Narro to export in addition.
Here's is my flow to translate in l10n-central:
* The cron job calls the automatic hg pull script every morning, and leaves
the log in http://translate.moztw.org/update-log.txt
* I go to Narro, import the en-US strings, make the translation
* Approve the translations, replace misplaced Accesskeys using ones from
en-US, export, and copy the exported files to our local l10n repo
* Check the strings to avoid typo to mistakes, clean-ups, and see the
compare-locales results, e.g.
http://translate.moztw.org/compare-locales/?app=browser&branch=central
* Commit and push, check dashboard few minutes later to see if there's any
problem
There're some issues like few strings in .properties file are not imported
to Narro's database, we made a little fix to the parser to let it be more
robust to import.
We also fixed some issues found in Narro, but I think it might have been
fixed in the 1.0.0 beta, and I'm considering to upgrade.
As a whole, I think Narro is quite easy and use to use as an localizing
tool.
Peter
2010/10/21 Armen Zambrano Gasparnian <arm...@mozilla.com>
Alexandru Szasz
https://l10n.mozilla.org/narro/data/import/14/Firefox%20Next%20%28mozilla-central%29_hy-AM_compare-locales.html
?
> * Narro should not offer certain texts to be translated if the
> LOCALIZATION NOTES indicates not to.
>
> Here is a blog post in the matter.
> http://armenzg.blogspot.com/2010/10/how-we-use-narro-to-localize-firefox.html
>
>
> Best regards,
> Armen
>
>
> On 10-10-17 2:45 PM, Axel Hecht wrote:
>> Hi,
>>
>> as you've seen in my other post, we're ramping up on outreach around
>> Firefox 4. As we don't know all the tools, we'd like you to follow up
>> here with how to do the smart thing with your tools.
>>
>> Might be good to reiterate on things like how to update the content on
>> web tools, export, intermediate files, etc.
>>
>> Also, for non-webtools, which versions of the tools are current.
>>
>> Thanks
>>
>> Axel
>
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
--
Alexandru Szasz
Armen Zambrano Gasparnian
>> I wish two things:
>> * beefier machine running Narro to navigate and searching faster
>> (exporting is good speed)
>> * compare-locales well integrated into Narro
>> ** output of it to point to the text on Narro so no more searching is
>> needed!
> Something like this:
> https://l10n.mozilla.org/narro/data/import/14/Firefox%20Next%20%28mozilla-central%29_hy-AM_compare-locales.html
> ?
This is soooo awesome!
When does it get triggered? When I export? or when new en-US strings get
imported?
Was this URL always available from the "Projects" page? I am so going to
blog about this :)
I love that I click on the entity and it does take to the page to fix it
before I download my exported project.
I will give it a shot next time and see how it is going to save my day.
Thanks alexxed!
Armen Zambrano Gasparnian
>> * beefier machine running Narro to navigate and searching faster
>> (exporting is good speed)
>> * compare-locales well integrated into Narro
>> ** output of it to point to the text on Narro so no more searching is
>> needed!
> Something like this:
> https://l10n.mozilla.org/narro/data/import/14/Firefox%20Next%20%28mozilla-central%29_hy-AM_compare-locales.html
> ?
Alexandru Szasz
I just added this for Firefox Next, I'll add it for the other projects.
It runs after the export. There's a link to that page, you can see it
under the xpi link and diff link after the export is finished. And also
on the project list. Just click on it, it opens in a new window.
It may be a bit delayed compared to what's on Mercurial (24h max)
because the import runs every night and I'm running compare-locales
against what en-US was downloaded then.
--
Alexandru Szasz
Dwayne Bailey
Since the POT files would come from moz2po they will have updated
POT-Creation-Date header which if you are retranslating using OmegaT
means you will also have this updated header
If you work with PO files then you're using po2moz so I don't know how
you can not get the issue of untranslated entries being inserted as
English.
None of the above applied of course if you really meant that you
translate .properties and DTD files directly in OmegaT and don't
actually use PO files.