Summary

• Progress has been made in i18n on mobile and customized mobile in the last few months.
• We have custom builds in which the user selects the next locale (via slightly modified language-slector pkg) and reboots into it
• Translations display for many/most applications (including Midbrowser via xpi debs, one of which, zh_TW, is now available from LP)
• For Asian locales, scim input methods are enabled and working

Among the topics I'd like to discuss and perhaps resolve this week are:

1. All apps in main so that they are in language packs

Answer: they shoud be, but some can't be. Work will be undertaken to move pkgs to main that should be there

1. All apps set up for translation so additional work can be done through LP
   • I'd like to define a list of what the collective wisdom in the room believes are the steps that needed to accomplish this for any given pkg

Answer: The new part here is universe pkgs being set up for translation. This needs to be researched.

1. Customizable langpacks per mobile project

Answer: Determine size of mo files in en_GB for pkgs in mobile and not main to determine whether mobile lang packs would use enough disk space to make desktop cd size problems. If not, it might be worth the effort, estimated at two days.

One note: disk size constraint: Mobile devices may possibly have disk constraints that argue for mobile specific language packs. Current projects don't, but disk utilization seems to continue to be a possible issue. Therefore mobile lang packs may make sense.

Rationale

• The usual user needs for i18n exist for mobile and custom mobile projects
• We add the possible requirement that the framework supports multiple projects containing different sets of pkgs

Use Case/Framework

• N number of custom projects, now need N + 1.
• New project has radically different set of pkgs exposing strings
• Do we:
  • Use generic desktop language packs (ie language-pack-gnome-ll and etc)
  • Use generic mobile language pack that contains supeset of all apps in all mobile custom projects?
  • Use project specific mobile language pack?

Answer: In the short term, the approach will continue to be a hybrid: mo files for pkgs in main are delivered in lang packs; and other pkgs (universe) deliver all their mo files with the package. This approach theoretically uses unnecessary disk on mobile devices. The resolution is migration of pkgs to main where possible and possibly deployment of mobile specific lang packs.

Use Case/Translator

LP:

• Custom projects may involve the need to accomplish missing translations quickly
• These might need to be done rapidly
• If all apps are in main and set up for translation in LP, third-party translators could use that interface, and the results are therefore automatically incorporated into lang packs

Non LP:

• po files are derived from latest source package with patches applied and provided to translators
• Resulting translations are manually pushed upstream and used in custom projects
• This approach is what we have today for most/many apps. It is complex and difficult to manage.

BoF Agenda and Discussion

• Should all mobile apps be in Main? They should, so where they cannot we look for fixes or replacements
• Should all mobile apps be set up for translation in LP? If possible, but tactically we can use manual methods
• Do instructions is exist for setting up pkg for translation in LP?
• Should there be mobile-specific language packs? Yes, but do not add a lot more space to the standard set Evaluate further - check list of CD supported language
• Should there be customizable (per project) mobile language-packs?
• scim replacement/enhancement? Apparently it is good but maybe not good enough for a top-notch Asian system. What alternatives? Are there open source handwriting analysis pkgs, for example? Arne will have a separate session
• supporting different hardware and virtual keyboards easily

UDS-Intrepid Notetaking

Breaking out mobile lang packs into their own package: 2 days of work

If mobile language packs are created, ensure they can be excluded from the desktop ubuntu CD

Any app can have translations on launchpad (say, from universe), but no prior art for making it so

Merge-o-matic (merges.ubuntu.com)

Add a facility to communicate changes from launchpad back upstream, for example, when a critical language is missing from the set of translations (this facility is needed in LP/Rosetta in general, so, communicating with the LP Translations Team should be first priority to solve this issue)

Hildon translations

* Could custom build .pot files to put on LP * Or could remove calls to hildon-text in each app

• Would we see new upstream releases and have to merge?

change strings in source code and use Launchpad

• effort now: medium
• translation effort: low
• maintenance overhead: high

convert in/out of standard po format and use Launchpad

• effort now: high
• translation effort: low
• maintenance overhead: low

do translation by hand without Launchpad

• effort now: none
• translation effort: medium
• maintenance overhead: none

Translations for packages outside main are technically possible, but consider first whether package is suitable for main. For Mobile Claws mail is an example of a package that cannot go into main because it depends on SendMail, which resent unacceptable security concerns.

Scim replacement

* Scim requires x restart * Input method may not be best for mobile devices