bzr-l10n team mailing list archive

[David Planella <david.planella@xxxxxxxxxx>]

Hi Alexander,

El dv 19 de 03 de 2010 a les 17:54 +0200, en/na Alexander Belchenko va
escriure: 
> Hi David,
> 
> Thanks for sharing your expertise and valuable hints.
> I have some questions, see below.
> 
> David Planella пишет:
> > (This is in response to an e-mail with a call for qbzr and bzr explorer
> > translations sent by Martin Pool, I'm re-sending it here as per Martin's
> > advice)
> > 
> > Hi Martin,
> > 
> > Thanks a lot to the Bazaar team for making these awesome projects
> > translatable!
> > 
> > I've noticed that both are translated with Open permissions. This is ok
> > if that is your decision, but perhaps you could consider using another
> > permission policy that puts the balance more on the quality rather than
> > on the quantity of translations.
> > 
> > The Launchpad help page summarizes the permission policies very well:
> > 
> >    https://help.launchpad.net/Translations/YourProject/PermissionPolicies
> > 
> > I'd personally recommend using a Restricted policy, assigned to the
> > Launchpad Translators group [1] [2]
> > 
> > With this type of permission, everyone with a Launchpad account will be
> > able to submit translations, which will then have to be reviewed by a
> > group of trusted translators before being included in the program.
> 
> OK, I understand the value of switching to Restricted policy.
> But I have one question though. Is it will be still possible for me to 
> upload POT templates via web-interface? Or I as maintainer of the 
> project, will be eliminated from translation process at all?
> 

That setting only affects who can submit translations for the project.
It has no effect on the maintainership processes. You will still be able
to upload POT templates through the web interface.

There is something else: perhaps this is a corner case, but I thought
I'd mention it anyway. It might be that you are a maintainer and a
translator at the same time. In that case, if you'd like to submit
translations for your language and don't want to join a translation
team, you could still commit your translations directly to the code.
Although I'd recommend rather joining the translations team and
collaborating with, rather than bypassing them.

> > This also helps with comunication: most of the translators in that group
> > are subscribed to the launchpad-translators mailing list, so whenever
> > you need to make an announcement or a call for translations, you just
> > need to post it there and translators will know that.
> > 
> > Using the code analogy, a Restricted policy is like with bzr and
> > branches, where everyone can create their own branches and merge
> > proposals (translation suggestions), but these merge proposals must be
> > reviewed by experienced developers before being merged to the codebase.
> > 
> > Having Open permissions for translation is like having an open
> > repository where everyone can commit. While this is great for having
> > lots of translations in little time, in my experience the quality of
> > these translations greatly suffers. This is for example, one of the
> > areas in which Ubuntu and Launchpad Translations have got most bad press
> > historically. In this and the previous cycle we started changing that to
> > make sure we can provide the best translations around while still
> > lowering the entry barrier for translators.
> > 
> > I could imagine that both qbzr and bzr explorer, being projects with
> > technical messages, might better benefit from their translations being
> > reviewed by experienced translators.
> > 
> > Also, you should definitely consider using:
> > 
> >       * Automatic bzr translation imports [3] [4]
> >       * Automatic bzr translation exports [5] [6]
> 
> Why you say "should"?
> 

I just thought they are such cool features that everyone should know
about them ;)

> I've watched the screencast you're mentioned here and I may say that I'm 
> not very impressed. There are some tiny details (and devil is always in 
> the details) which makes me a little unhappy with automatic imports/exports.
> 
> 1) The template which is generated by GNU xgettext utility and template 
> and I've got by exporting from launchpad has some differences. Therefore 
> each time I have to deal with big enough diff between those 2 versions.

The only differences the templates should have are in the metadata (the
header and perhaps the order of strings), but the important part are the
messages themselves, which should not differ.

In any case, you shouldn't generally be keeping the POT template under
version control (unless you are using automatic imports, more on that
later) or exporting it from Launchpad. The POT file needs only to be
generated and given to translators (well, in your case uploaded to
Launchpad) before releases, as part of the build or manually. The
metadata differences there might be between the template created by
gettext and the one exported from Launchpad are irrelevant for
translators or maintainers.

So, with your current setup, the workflow could be:

1) Before a release, create a POT template
2) Upload it to Launchpad. All translatable strings will be exposed
there
3) Send out a call for translations
4) When you are ready to release, request an export of translations from
Launchpad
5) Commit the translations (PO files) in the exported translations
tarball to your branch. 
6) Release! :)

>  
> Even if I do a simple round-trip, e.g. collect strings with xgettext, 
> upload to LP, wait for processing it in the Import Queue, then simply 
> download it from LP I'm always get something different. I don't like 
> this behavior. So last year or so I'm even don't try to commit the POT 
> generated by xgettext, but instead I'm just simply uploading it to LP, 
> and only commit the files which I've got on export from LP.
> 

That's exactly the expected workflow. The POT template can always be
regenerated and it is generally not useful to keep it under revision
control. The changes in the metadata are generally too big to produce
useful diffs anyway, and if you look at some of the major Open Source
projects using localization (GNOME, KDE, GNU, etc.), you'll see that the
POT templates are not in their repositories.

> 2) There is some restrictions on naming of POT and used directories. I 
> don't like the idea to put the messages.pot to the root of the 
> development tree, as I can see on the screencasts.

Perhaps there has been a misunderstanding here. You don't need to change
your current layout.

Looking at 
http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk2a/files/head%3A/po/ and
http://bazaar.launchpad.net/~bzr-explorer-dev/bzr-explorer/trunk/files/head%3A/po/

po/qbzr.pot and po/explorer.pot are absolutely fine.

You see that the templates comply with the import policy as outlined in

https://help.launchpad.net/Translations/YourProject/ImportPolicy#Sample%
20directory%20layout

That policy was drafted following standard GNU naming practices, and
it's the one most translatable Open Source projects follow. 

There is something I should mention regarding the translations, though.
It is a convention to name them simply after the language code (e.g.
ll.po or ll_CC.po). That is, simply 'ar.po' and 'zh_CN.po' instead of
'explorer-ar.po' and 'explorer-zh_CN.po'. If I'm not mistaken, the
convention stems from some build systems relying on that naming scheme,
and it makes easier to identify the files with language codes.

For this reason, I'd recommend you to remove the 'explorer-' and 'qbzr-'
prefixes from the .po files.

>  Today we have a 
> reasonable files structure, e.g. all translations located in the po/ 
> directory and domain name of translation is the same as the name of 
> project (e.g. qbzr.pot for QBzr and explorer.pot for Bazaar-Explorer).

Yes, that's absolutely fine.

>  I 
> don't like the idea I should switch to faceless message.pot today. Also 
> we have a very automated system to collect messages from all source 
> files, and compile translations to MO format. All these done as 
> distutils commands, so I can use either:
> 
> python setup.py build_pot
> (to generate POT with xgettext and optionally update PO files with msgmerge)
> 
> python setup.py build_mo
> (to compile all PO files to corresponding MO files of the right domain)
> 
> I'm also have this command:
> 
> python setup.py import_po
> 
> which is used to automatically get the files from the 
> launchpad-export.tar.gz with translations exported from LP and put those 
> files where they should be.
> 

You don't need to change your current layout, so your build
infrastructure should work as normal.

> I think automatic import/export of POT/PO might be good idea for big 
> projects, but both QBzr and Bazaar Explorer is small enough so we can 
> handle with these 3 commands above.
> 

Automatic import and export can be useful regardless of the size of the
project. It not only benefits maintainers, but also translators.

Of the 3 commands above,

      * build_pot: you'll have to run it anyway to generate the POT
        template. Note that in the near future Launchpad will we able to
        automatically generate it, saving you this step. For now,
        though, you still have to do this manually. For automatic
        imports to work you'll have to manually update the POT template
        with the build_pot command and commit it to the branch.
      * build_mo: will have to be executed anyway, since it is part of
        the build infrastructure of the project, which Launchpad does
        not have influence upon. In any case, I believe you shouldn't
        need to execute this manually, as your build tools should be
        take care of calling it.
      * import_po: with automatic exports you no longer need to execute
        it, as the changed translations will be committed daily to your
        branch of choice. As a maintainer, that will be a further step
        towards automation, and will save you time and manual work. For
        translators, they will know that their translations will be in
        the code straight away and they won't have to rely on the
        maintainer manually exporting them and integrating them in the
        code.

> Also I'm not really sure is there is required 2 separate branches: one 
> to use as import source, and other to use as export target.
> 

That's entirely up to the maintainer. You can use the same single branch
for the code and for automatic commit of translations. Some developers
or maintainers prefer not to have automated commits in their trunk
branch, but rather having them in a separate branch and merge them
manually to trunk.

> > Which are in my opinion two of the coolest features the Launchpad
> > Translations team has developed in recent times. The benefit for
> > translators is that they know that their translations are always
> > integrated in the code, and for maintainers is that they only have to
> > worry about updating the template and announcing a call for translations
> > before a release, all the rest is automated.
> 
> Maybe you're right, so may be you can help us to setup automatic 
> import/export for our existing branches so we can see it in action?
> 

Yeah, sounds like a good plan. As I said, it would be just cool if two
projects such intimately related to bzr could make use of a feature also
built upon bzr.

You can ping me on IRC I'm in #launchpad and #ubuntu-translators among
other channels on Freenode on CET time (nick: dpm) and I can give you a
hand if you need it. The Launchpad Translations developers (danilo,
henninge, jtv, Ursinha) are also on #launchpad and will gladly help you
as well.

E-mail is also fine.

Basically, if you want to try this, the basic steps will be:

     1. Rename the qbzr-ll.po (and explorer-ll.po) files to ll.po (where
        ll is the language code, which might include a region code as
        well, in which case it'd be ll_CC.po)
     2. Go to
        https://translations.launchpad.net/qbzr/trunk/+translations-settings (and to the bzr-explorer one) and set up the import and export settings
             1. Since translations are already in Launchpad, I'd simply
                choose "Import template and translation files" in the
                import settings
             2. For the export, you can choose your trunk branch or a
                separate one. Note: you can read the details here [1],
                but watch out that "At the moment, team-owned branches
                don't work as expected. To work around this, make
                yourself the owner of the branch, set it as the
                translations branch, and then make the team the owner of
                the branch again."
        
> > If you need any help in setting up the permissions or any questions on
> > translations, feel free to ping me (or any of the Launchpad Translations
> > developers) on #launchpad, and I'll be glad to help.
> 
> I will be very grateful to get some comments on the items I've 
> highlighted in this mail. IRC is good, but for the sake of sharing 
> wisdom between QBzr and Bazaar Explorer developers, I'd prefer using 
> e-mail at this stage.
> 

Sure, I hope you found the replies useful. Just let me know if there are
more open questions and if I can help in any way.

Thanks for caring about translations!

Regards,
David.

> Thanks,
> Alexander
> 
> > 
> > Regards,
> > David.
> > 
> > [1] https://translations.launchpad.net/+groups/launchpad-translators
> > [2] https://help.launchpad.net/Translations/YourProject/ChoosingAGroup
> > [3] http://blog.launchpad.net/translations/import-translation-templates-from-your-projects-bazaar-branches
> > [4] http://blog.launchpad.net/translations/screencast-importing-translation-templates-from-a-bazaar-branch
> > [5] http://blog.launchpad.net/general/exporting-translations-to-a-bazaar-branch
> > [6] http://blog.launchpad.net/translations/screencast-exporting-translations-to-a-bazaar-branch

[1] https://help.launchpad.net/Translations/YourProject/Exports

-- 
David Planella
Ubuntu Translations Coordinator
david(dot)planella(at)ubuntu(dot)com
www.ubuntu.com

Attachment: signature.asc
Description: Això és una part d'un missatge signada digitalment