It was suggested that hildon-desktop may have performed (and may
still perform) string translation in a manner that is inconsistent
with translation via Launchpad.
It appears to me that hildon-desktop uses the gnome gettext approach
to internationlization for the following reasons:
1) grep hildon-desktop source for the gnome header that defines gnome
i18n stuff and you get:
[EMAIL PROTECTED]:~/src/hildon-desktop/hildon-desktop-0.0.21/src$
find . | xargs grep i18n
./hn-others-button.c:#include <glib/gi18n.h>
./hn-app-tooltip.c:#include <glib/gi18n.h>
./hd-select-plugins-dialog.c:#include <glib/gi18n.h>
... etc.
2) grep for "_(", the gnome standard gettext() post macro
substitution, and you get some 50 or so instances in hildon-desktop
source.
3) I can use xgettext from the command line to generate a messages.po
file.
Can someone confirm/refute?
The next question is whether hildon-desktop is translated upstream (I
suppose that's gnome?) or in Launchpad. Launchpad reports it is not
set up for translation. Anyone know?
Lastly, am I correct in thinking that if hildon desktop uses gnome
gettext and is not translated upstream then there is no theoretical
obstacle to its being set up for translation in launchpad?
Thanks,
Kyle
On Nov 20, 2007, at 5:48 AM, Matt Zimmerman wrote:
> On Mon, Nov 19, 2007 at 04:42:41PM -0500, Kyle Nitzsche wrote:
>> Hi Matt and David
>>
>> I have the task of drafting a spec/blueprint for Mobile
>> Internationalization, due this week.
>>
>> My question is: is such a spec actually appropriate given that
>> i18n is a
>> well-known problem with a well-known solution. (I created it way
>> back, but
>> now have second thoughts.)
>
> Mobile has some specific issues here, given the strange way that
> Hildon does
> i18n, unless that's been fixed. Until it is, I don't think it can be
> translated in Launchpad as other applications are.
>
> A decision needs to be taken on our approach to shipping
> translations, e.g.
> can we use the existing language pack system or not?
>
> It's also worthwhile to state what our goal is with respect to i18n
> in the
> form of a specification.
>
> So yes, I'd say it's worth writing down the plan from an i18n point
> of view.
>
>> What may be more useful is a wiki page that concisely reports the
>> i18n
>> status of each mobile app and the hildon desktop respecting i18n.
>>
>> App i18n status might include:
>> --It uses an approach other than gettext (like mozilla browser),
>> in which
>> case (I presume), the app needs a dedicated language pack
>
> I'm not sure what Alexander has planned for translations for
> midbrowser,
> best to ask him.
>
>> --It does not using any approach yet, so source code needs
>> modification to
>> use gettext (all hard coded strings)
>> --Its code uses gettext, but it's incompletely i18nized (some hard
>> coded
>> strings)
>> --Its code uses gettext and it is complete (no hard coded strings)
>>
>> There has been development of an "Application Criteria" list via
>> the mobile
>> list in the last few weeks
>> (https://wiki.ubuntu.com/MobileAndEmbedded/
>> UserApplicationCriteria). It's
>> too long right now, and it should probably be divided into Must
>> Haves
>> (like hildonization and being setup for translation), Nice to
>> Haves and
>> maybe Quantifiers (disk footprint, memory usage, etc). Adilson
>> received an
>> action item to apply that list to each application in core in last
>> Thursday's Mobile IRC weekly: perhaps that is all that's needed?
>
> I agree that it's useful to assess the i18n status of each
> application, but
> independent of that, there's more to be decided and implemented
> regarding
> i18n.
>
> --
> - mdz
--
Ubuntu-mobile mailing list
Ubuntu-mobile@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
