Hi,
El mié, 21-11-2007 a las 09:17 +0100, Loïc Minier escribió:
> On Tue, Nov 20, 2007, Kyle Nitzsche wrote:
> > 2) grep for "_(", the gnome standard gettext() post macro
> > substitution, and you get some 50 or so instances in hildon-desktop
> > source.
>
> The problem is that you get "code" strings, not strings to actually
> translate, for example from grep _( in hildon-desktop:
> #define AS_HOME_ITEM _("tana_fi_home")
> #define AS_CLEAR_ITEM _("tana_fi_clear_received_events")
> #define AS_CLEAR_CONFIRM _("tana_nc_clear_events")
> ...
> #define PING_TIMEOUT_MESSAGE_STRING _( "qgn_nc_apkil_notresponding" )
> #define PING_TIMEOUT_RESPONSE_STRING _( "qgn_ib_apkil_responded" )
>
> You can't expect translators to see "qgn_nc_apkil_notresponding" and
> translate it as "Timeout: not responding" or something.
Indeed, I cannot understand how's that they did it in that way using
gettext...
>
> Also, there's some usage of custom macros like _L10N(), I don't know
> whether these can be scanned for; probably with some help.
That's easy to workaround, xgettext command has a --keyword argument to
specify such custom macros.
>
>
> However, my understanding from UDS/AllHands discussions was that we
> probably can live with such code names because Launchpad/Rosetta might
> display other translations of the strings, so if we have for example
> the English translation of the string, Rosetta might display this when
> someone is trying to translate qgn_nc_apkil_notresponding into Chinese.
> I hope I understood the above correctly, but please anybody correct
> me if this is incorrect.
In Launchpad Translations we have support to import Mozilla Firefox
translations which uses the same 'feature' to identify msgids, so we
have most infrastructure in place already to cope with that. The idea is
that we will define a new file format, for instance HildonPO, which is
the same as a PO file but with id for msgid and using en.po en_US.po or
whatever you tell us that they use to store the English strings as the
main catalog of strings. From there, our translators will see regular po
files in Launchpad Translations and even download them to use offline
tools. At the same time, we keep the option to get the HildonPO format
which has the ids as part of the msgids which could be used to send
updates to upstream or to deploy those translations in our language
packs.
The only problem I see with this solution is that we need a way to
detect those special po files automatically to differentiate them from
regular po files. In worse case, we could do that manually per .pot
file, but we would prefer to not do that so we can focus on development
instead of doing boring review work like that.
Btw, as far as I know, Nokia is already thinking about how to move to
use gettext in the right way so this problem should be gone at some
point.
Cheers.
>
> --
> Loc Minier
--
Ubuntu-mobile mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
