On Tue, Jul 13, 2010 at 6:57 AM, Andreas Volz <li...@brachttal.net> wrote:
> 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?
Edje file format will be broken is the coming month (to improve memory
layout, load time and manipulation speed. It should also help edje
edit regenerate edj file with script). I have some plan to make old
file format readable to new file loader. That's why I am making this
RFC, it's a good time to add feature to Edje file format.
So yes, it's a breaking period, yet again,
--
Cedric BAIL
------------------------------------------------------------------------------
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
