Re: GNU gettext for hildon?

[Kyle Nitzsche <kyle nitzsche canonical com>]

Hi Tommi and all, 

The work around suggested below to address the current Hildon issue of non-meaningful strings in code for translatable terms is to use the en_GB.po files made available through the Hildon project to deduce the intended meanings (in English) of the currently non-meaningful strings in code. Translation could then be done, theoretically, manually anyway ;) (without Launchpad/Rosetta).

Couple questions:

---------How many of these en_GB po files are there (and are they complete)? ----------

Or put another way: how do I get the complete set of Hildon package translations for English/Great Britain? 

If I look in the module directories at http://live.gnome.org/Hildon/TwoPointZero/ModuleOverview, I get:

 * hildon-desktop has a po/ dir, but no en-GB.po file

 * hildon-1  has a po/ dir and an en_GB.po file

 * hildon-fm has a po/ dir and an en_GB.po file

 * hail has a po/ dir but no en_GB.po file. 

None of the other modules has a po/ dir. Is it therefore safe to assume no other Hildon modules expose strings that need translation?

It appears that two of the en_GB.po files are missing, which seems odd (hildon-desktop, hail). Should these packages have en_GB.po files?

---------Suppose new strings are introduced? ----------

Suppose I modified the Hildon source and introduced new strings, how could translations be handled (until such changes were accepted upstream)? 

I presume I could create new po template(s) from source, then merge them with any existing translations (po files), and, since my new strings would use meaningful English, they could be translated. 

Sound doable?

Cheers,

Kyle

On Feb 25, 2008, at 4:36 AM, Tommi Komulainen wrote:

On Fri, 2008-02-22 at 11:59 -0500, ext Kyle Nitzsche wrote:

Hi,

It appears that Hildon does not use standard GNU gettext.

The strings in code that are destined for exposure in the user  

interface are not meaningful English, which I believe they should be  

in order to facilitate/enable translation.

The issue with localisation is well known and discussed in depth last
year. Please see the full thread on maemo-developers:
http://lists.maemo.org/pipermail//maemo-developers/2007-October/012056.html

In short: Nokia needs to figure out in excruciating detail how it needs
to change processes to be able to use gettext normally.

One implication of this is that Hildon cannot be readily translated in  

systems where the strings in code are displayed as the basis for  

translations, like launchpad.net.

As we do make en_GB translations available, launchpad (or rosetta) could
theoretically make use of that as the basis instead. IIRC Adilson in
principal agreed.

I know that's not helping much :-/

1) Should Hildon be modified to implement GNU gettext i81n?

Yes. This would be trivial, but...

2) Is the only change required fixing the strings to be meaningful  

English or are there other non-standard aspects?

...we also need to change our processes to match. This is non-trivial.

3) Should Hildon packages be set up for intltool as a further step  

towards standardized i18n?

intltool is required only if you have other than C files to translate
(.desktop, .schemas, .xml, etc - see intltool-update) -- if you don't, I
don't know it makes much difference.


--
Tommi Komulainen                            <tommi komulainen nokia com>
_______________________________________________
hildon-list mailing list
hildon-list gnome org
http://mail.gnome.org/mailman/listinfo/hildon-list