This pages summarizes information on UME and langpack.

Overview of langpacks

The concept of language packs is well explained in the TranslationLifecycle page.

Gain for a mobile langpack

UME borrows packages from main for which we have translations in the default and in the GNOME langpacks; ArneGoetje was kind of enough to estimate that the difference between installing the German default and GNOME langpacks and installing an imaginay mobile langpack with only German translations for the mobile packages would save us 10 MB.

Issues of Hildon modules

Hildon modules use message codenames instead of English language strings in the code; this is not supported by Rosetta, and hence we need to massage the po/en_GB.po po/*.pot and po/*.po files to get normal looking po files in the source packages and upload them to Launchpad.

Hildon modules also share translations or split the translation data in separate sources; it makes it harder to locate where the translations actually are and we might be missing many modules transporting translaions.

String Freeze and Mobile Roadmap

The UME roadmap still requires string / UI changes after the Ubuntu string / UI freeze (28th February for Hardy); we need to be able to translate source packaegs of mobile packages or packages modified for UME (in the ubuntu-mobile ppa) after the freezes.

Limitation of Rosetta

If two binary packages for different architectures are uploaded to the archive with different strings, the latest upload "wins" and the removed strings are obsoleted. You should make sure that packages have the same strings (pot files) for all arches, e.g. apply the same patch stack for all arches.

TODOs / Roadmap

  • Hildon modules use more than one gettext message domain at the same time; for example hildon-1 defines c_(s) to dgettext("hildon-common-strings", s) and _(s) to dgettext("hildon-libs", s); we need:
    • - a module -> list of used gettext domains map - a gettext domain -> upstream module/source map - to package the missing upstream modules/sources as discovered above or merge their translations into the consumers

  • Hildon modules use logical message ids (e.g. "ecdg_ib_passwords_do_not_match") instead of English / "programmer" strings; Launchpad should hopefully get support for using the English translation as the displayed string when translating to other languages but in the mean time we need:
    • - a script to convert upstream's en_GP.po and/or pot (id based) into more conventionals pot (English based) before the Launchpad import; this script should be used at build time, from the debian/rules of Hildon packages - a script to convert back the Launchpad exported translations, probably .mo files in a tarball, into id based translations; ultimately, this should be implemented in langpack-o-matic, but it might be run separately before langpack-o-matic on the exported Launchpad tarball in the mean time; some useful pointers:
      • this is also required for Firefox (XPI-based) translations
      • this is also required for, but implemented outside of langpacks (need to confirm with ChrisCheney how it's done ATM)

      • there was a merge-tarballs script in langpack-o-matic which is still reachable in bzr history which might turn useful to do this
  • langpack-o-matic changes:
    • - langpack-o-matic needs new templates for the new mobile langpacks packages; trivial short job

      - langpack-o-matic is currently based on heuristics to decide in which langpacks a package belongs (for example a dependency on Gtk+ suggests it should be stuffed in the GNOME langpack, unless it's also used for KDE); this isn't really fit for Mobile packages which also often use Gtk+; one solution is to use seeds, and MartinPitt seemed to think this would be a worthwhile change for all langpacks; it probably requires close to day a work and checking that the new logic doesn't change the contents of the existing langpacks (or why it does) - langpack-o-matic also expects translations to be into a single langpack; for the mobile langpack, we want to save space by only installing translations we need, nothing less, nothing more, and hence we need an update to the langpack code to allow translations to be copied into e.g. the gnome and the mobile langpacks; we also need Conflicts with the other langpacks packages; relatively easy job - estimated total amount of langpack-o-matic work: more than a day, probably less than two days; probably to be done by MartinPitt or ArneGoetje

  • Post freeze and PPA packages translations: after the string/UI freezes in hardy, we still want to update the mobile langpacks, based on newer packages in the ppa; this requires:
    • - creating a new Launchpad project (we can't use Ubuntu as this would pollute/confuse translation teams) and setting up translation teams - uploading our packages' (with "fixed" pot) to the translations area of the project - telling translation teams to translate - retrieving the translations tarball - running the same langpack-o-matic magic (with fixup script) and uploading the resulting mobile langpack source package to the mobile ppa

MobileAndEmbedded/MobileLangpack (last edited 2008-08-06 16:16:15 by localhost)