[i18n] integrate gettext and use translations from Unity

[Florian Boucault]

In order to be included in main we need to integrate properly with launchpad's translation system. To achieve that 2 actions need to be taken:
- convert Qt string catalogs automatically to .po catalogs upon Debian package building
- write a launchpad translation export filter to Qt native i18n system

[Kyle Nitzsche (knitzsche)]

Just noting that integration of QT with LP is actually a platform issue since they may/will need to support this. I believe DBarth has communicated with QT developers on this. I think this bug may therefore be invalid for this project at this point. Our need is to make our packages work for now in our OEM projects for translations.

[Florian Boucault (fboucault)]

Having the translations in the source package was deemed acceptable for inclusion in main.

[Florian Boucault (fboucault)]

see https://bugs.launchpad.net/unity-2d/+bug/682858 for implementation

[Florian Boucault (fboucault)]

Reviving that bug since comment #2 was not yet backed by anybody with authority yet. Having the translations in the source package might not was deemed acceptable for inclusion in main.

[Jonathan Riddell (jr)]

A better option would be to use gettext directly in the application.

For strings in code you should be able to use normal gettext functions.

For strings loaded from .ui and qml files you would need to install a translator QCoreApplication::installTranslator() which would be a simple class that calls gettext. See kglobal_p.h and kglobal.cpp in kde4libs for an example.

This would have the added benefit of easily being able to share strings with the original Unity while not having maintian a fiddly convertion from .ts to .po files.

[Kyle Nitzsche (knitzsche)]

Using gettext natively is the best solution I think because it means there are no (?) issues with integration with launchpad translations and delivery of translations via language packs (should qt apps end up in main) .

[David Planella (dpm)]

+1 on using gettext natively too.

We do this for language-selector and usb-creator already, which allows us to have one single source for messages to be translated in Launchpad, as well as one single set of messages installed in a central location in the system.

See Jonathan's summary on the state of Qt translations:
https://wiki.kubuntu.org/QtTranslations

Having this generic class that calls gettext instead of the Qt translate call would not only be useful for Unity, but also for any other Qt application, now that we're embracing Qt apps in Ubuntu.

[Florian Boucault (fboucault)]

Thank you for the good tips Jonathan! It looks like a small effort for us to use gettext. Let's do it!

[David Planella (dpm)]

Apart from modifying the code, in order to have full internationalization support there are two other items to consider:

1. Modifications to the build system to build and install the translated files provided by Launchpad
2. Modifications to the Debian package to import those translations

In general, 1. is already taken care of by the relevant autotools rules. However, if I'm not mistaken unity (the 3d version, at least) is using cmake. cmake has, as far as I know, no standard rules for internationalization. This means we'll have to write them ourselves.

Fortunately, Didier Roche is working on this already for Unity (3D) in bug 697166, so I'd suggest you to get in touch with him.

As per 2., what needs to be done is to add a rule to debian/rules to build the translation template (the unity.pot file) upon build. Didier has been working on this too as part of bug 697168, so again, I'd recommend getting in touch with him.

[Florian Boucault (fboucault)]

Thank you very much for the information David, that will be very useful to us.

[Kyle Nitzsche (knitzsche)]

To be clear on one point, there was some discussion that unity-2d package would simply use the "unity" gettext domain. That is, unity-2d would not carry po files in the source pkg, would not be translated in Launchpad, would not generate .mo files at build time, and would not install .mo files for use at run time. Instead, it would simply call the "unity" domain and obtain required translations at time. While this is based on the idea that unity-2d should not use messages that are not present in unity, this is probably not a good idea. It would mean that unity-2d would not be capable of adding messages (and having them translated) that may be needed. If unity dropped a message, unity-2d would have to be certain to remove the message as well or it would appear untranslated. Lastly, If unity-2d needs to be customized, it should support the normal package translation capabilitieus.

[Florian Boucault (fboucault)]

Kyle, thanks for that important precision.

Our goal is to have Unity 2D 100% in sync with Unity in terms of features and certainly in terms of string. So in theory that should not be a problem.

The fact that we will probably want to customize Unity 2D is very critical though. At least for that reason we should have our own domain.

[Kyle Nitzsche (knitzsche)]

Note that due to Launchpad Translation "suggestions" capability, I expect that all unity translations should be available for selection in the unity-2d LP translation UI. Even so, it would save translators work to go and get the unity po files (at an appropriate time) and use them as the base (in bzr/src pkg) before enabling translations formally in LP for this project.

[David Planella (dpm)]

El dj 03 de 02 de 2011 a les 14:31 +0000, en/na Kyle Nitzsche va
escriure:
> Note that due to Launchpad Translation "suggestions" capability, I
> expect that all unity translations should be available for selection in
> the unity-2d LP translation UI. Even so, it would save translators work
> to go and get the unity po files (at an appropriate time) and use them
> as the base (in bzr/src pkg) before enabling translations formally in LP
> for this project.
>

+1

One thing we can do, given the fact that Unity (3D) is already
translatable in Launchpad, is to simply fetch the translations (PO
files) from there and commit them to the Unity (2D) branch prior to
exposing it for translation in Launchpad.

This will not avoid duplication of translation work, but it will reduce
it to the minimum.

An appropriate time to do this would probably be around UI Freeze, when
the Unity messages will be stable and when most of the translation
activity happens.

--
David Planella
Ubuntu Translations Coordinator
www.ubuntu.com / www.davidplanella.wordpress.com
www.identi.ca/dplanella / www.twitter.com/dplanella

[David Planella (dpm)]

I've just approved the translation template the latest package upload correctly produced.

Now that message sharing works between projects and source packages, we should perhaps have a chat next week about enabling translations in the upstream project in Launchpad, so that translations done in the source packages can flow to upstream and be automatically committed to bzr through automatic translation exports.