Desktop and Translations Roundtable

Work items:
[robert-ancell] Implement gettext support for PolicyKit: INPROGRESS
[ccheney] Check with upstream the status of building OO.o language packs separately: POSTPONED

Topics discussed:
* Overview of Launchpad Translations changes in Maverick: automatic generation of translation templates, import of translations from upstream bzr branches and translation sharing. This will also be explained in a plenary.
* Implementing gettext support to PolicyKit
* Firefox and OpenOffice.org translations status
* Common approach for building POT template on non-desktop packages using plain gettext instead of intltool, e.g. mountall, in the same way as CDBS GNOME packages use langpack.mk
* Could langpack-o-matic build the translated XML files for documentation to be shipped in language packs? Even if we cannot get it to build for all packages, even if only for ubuntu-docs would be a big improvement.
* Enabling keyboard indicator applet by default on users with a non-Latin alphabet keyboard layout (see https://bugs.launchpad.net/bugs/550704)?
* Evaluate the use of mlterm instead of VTE for RTL locales?

Session notes:
Imports from bzr branches
 Message sharing between imported upstream projects and Ubuntu: imported projects are read-only
 Packages should still generate POT templates, changes to that in upstream will be imported automatically
 Recreation of POT templates:
  * Intltool layout supported
  * Might add other formats in the future
 Translations from Debian patches will in principle not be imported

* Seb, Robert: it would be doable to implement this on this cycle
 * We'll need to talk to upstream, see if they would accept this functionality there as well
* FF and OO.o translation status:
 * Better talk to Chris Coulson for Firefox
* OO.o 3.2.0 in Lucid, OO.o 3.2.1 as backport
* OO.o 3.2.1 in Maverick
* Chris will be working for the server team this cycle, so won't have much time for this, but will happily accept patches

* We'll try to sort out the OO.o menu translations (#512395)

* Idea: Create and advocate a standard make target to build translation templates (POT files). It should simply return the list of generated files. Patch in Lauchpad and provide back upstream.
* Provide a "standard" i10n cheat sheet for maintainers to follow. (Robert)

* Keyboard indicator will be enabled by default.

* Discussion on using mlterm for RTL languages (post-UDS, on IRC):

mai 20 10:03:34 <dpm> hi ArneGoetje, we didn't have the chance to talk about it at UDS: what's your opinion on using mlterm instead of vte for RTL languages? Would something like that make sense in Maverick? Could language-selector install it on a per-language basis? I don't know if it can be embedded in e.g. gnome-terminal as VTE, do you?
mai 20 11:14:34 <ArneGoetje> dpm: AFAIK mlterm is standalone and cannot be embedded into gnome-terminal. We can install it additionally for some languages, yes.
mai 20 11:16:12 <ArneGoetje> dpm: but I think we should get this bug fixed upstream (vte)
mai 20 11:19:11 <dpm> ArneGoetje, the thing is that IIRC the maintainer's comment, it is extremely hard to fix, and this is not likely to happen
mai 20 11:19:27 <ArneGoetje> dpm: :(
mai 20 11:20:30 <ArneGoetje> dpm: maybe we can ask the mlterm maintainer to make mlterm embeddable in gnome-terminal as vte?
mai 20 11:35:56 <dpm> ArneGoetje, yeah, that'd be a good start. If that were possible, would it be possible in turn to replace VTE on a per-language basis during the installation?
mai 20 11:37:28 <ArneGoetje> dpm: IF mlterm would be interchangable with vte, then yes. Although when using Indic languages, one needs to specify the exact language as an option to mlterm... means, we need different configurations for each language.
mai 20 11:38:22 <ArneGoetje> dpm: however, mlterm uses xcore or xft to draw fonts... that may be a step backwards
mai 20 11:39:48 <dpm> ArneGoetje, I'm not that much into terminals or fonts, what does that exactly mean?
mai 20 11:40:48 <ArneGoetje> dpm: means we will need to test if the font rendering is acceptable.
mai 20 11:49:06 <ArneGoetje> dpm: seems mlterm does not use fontconfig... so that will be a step backwards
mai 20 11:51:14 <dpm> ok, thanks for the clarification
mai 20 11:59:12 <ArneGoetje> dpm: confirmed. mlterm does not use fontconfig... and can't display Arabic out of the box... we would need to configure mlterm to use the proper Arabic fonts.
mai 20 12:00:53 <dpm> ArneGoetje, do you know anyone or have any contact on mlterm upstream?
mai 20 12:01:05 <ArneGoetje> dpm: nope
mai 20 12:01:57 <dpm> ArneGoetje, do you think mlterm could be the way to go for RTL languages if the issues about embedding and using fontconfig are sorted?
mai 20 12:03:40 <ArneGoetje> dpm: if that could happen, then I think mlterm is the only way to go, if they want to be able to display their filenames and translations on the console.
mai 20 12:05:06 <dpm> ArneGoetje, so what do you think would be the way forward, to file a bug for each one of these issues?
mai 20 12:06:08 <ArneGoetje> dpm: chat with upstream first, if upstream is still active, and ask if they could implement these features and if yes how much work it is.
mai 20 12:07:49 <ArneGoetje> dpm: if upstream says yes, let's hope it will be ready for maverick. if they say no, we need to patch the package to include proper font configurations for RTL languages by default.
mai 20 12:08:29 <ArneGoetje> dpm: and mlterm would only be optional to what we have currently.
mai 20 12:09:53 <dpm> right, thanks
mai 20 12:10:40 <ArneGoetje> dpm: frankly speaking, I think mlterm has some nice features when it comes to proper script handling. But all together it seems to be several years behind in development...
mai 20 12:11:23 <dpm> ArneGoetje, you mean behind in terms of activity or technology?
mai 20 12:11:35 <ArneGoetje> dpm: technology