Am Fri, 9 Jul 2010 18:57:49 +0200 schrieb Cedric BAIL:
> Hi folks,
>
> I have been spending some time thinking about internationalization
> for edje file lattely with a few people around. So here are a
> technical proposal that I can implement at the end of Edje file format
> rewrite. As it will touch every one, I did include more than just dev
> mailing-list.
>
> First to put some background around this proposal. We want to push
> more the use of Edje for application layout (thanks to the always
> improving Elementary external support). This mean that a lot of string
> end up inside the Edje file. And they will depend on the Edje file
> content. So it's not really acceptable to set the text from outside of
> Edje. We want to distribute themes with their translation easily, we
> have one efficient file to distribute, eet, and it should stay that
> way.
> Gettext is huge, but it lack the possibility to use pointer to
> memory as a possible dictionnary, so we can't easily use it with eet
> file. But their is a lot of tools around gettext to manipulate .pot
> and .po files. So we need to follow gettext file format or it will
> make translator life a bit to hard.
> Some language would need to completly change the edje layout, look
> at GNOME Arabic support to see what I mean. They basically move widget
> around. This would require to localize group inside edje and add a lot
> of code around that. I don't want to support that kind of use case.
> It's highly specific, and people that want to do so, should support it
> in their apps.
> From this, I want to only support text, but not with gettext help
> still by using its pot and po files.
>
> So here we go, I want to add to edje_cc scanner the detection of
> this kind of syntax: _(TEXT_ID) in every exposed string to the user.
> Maybe, I should be able to add another stage before CPP, that would
> move /// comments to another form, so that they are still available
> when doing the parsing and could be added during .pot generation. In
> the case of _(TEXT_ID), edje_cc will store a NULL in the string
> pointer and a new index (int) will be added to all structure in Edje
> that need it. After the parsing stage, I will generate a mapping from
> ID to unique number, that may take into account a preexisting mapping
> description file (this should prevent the loss of translation where
> commented part would have been removed from the resulting mapping, so
> preserving all already existing translation). When this mapping is
> done, all int inside Edje structure will be update correctly, and the
> mapping will be saved inside an eet section
> ("edje/localization/mapping").
> Edje will also not generate any file if the target exist and does
> have a localized content, if you don't provide a specific command line
> argument.
> Translation will just be stored as an array of string where NULL
> mean no translation.
> Edje_calc will check if a string is NULL and mapping index > 0, if
> so it will load the right array of string and just jump at the right
> index. If their is no translation, it will fallback to a default
> language in that case
>
> A few new tools:
> - edje_xgettext will generate the .pot file from the Edje mapping
> information.
> - edje_msgfmt will insert a .po inside an existing Edje in a Eet
> section ("edje/localization/en_us") as a array of string (not
> translated string will be NULL). It should show the percent of
> translated string and do some check if the translation already exist
> (like overridding existing content and stuff like that).
> - edje_msgunfmt will extract a .po from an Edje file.
> - edje_locale will display statistic of all translation of an Edje
> file.
> - edje_locale_default will alias a translation as Eet section
> ("edje/localization/default") that will be used by edje_calc.
>
> And that's all ! What's your opinion ?
Nice idea!
Will this break all existing Edj files? Or is this change binary
backwards compatible?
regards
Andreas
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
