On Fri, Jul 9, 2010 at 7:57 PM, Cedric BAIL <[email protected]> wrote:
> 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.
>
That's great.
>
> 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.
>
I agree, as a user of the API, I had to set the text from the C program
instead of just enjoy putting the text in the edje.
> 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.
>
Regarding Arabic support: It should be done transparently behind the scenes,
I'm currently working on that, but as said, it's not and should not be part
of the
new edje format, as it will be done without the developer intervention.
Maybe
(probably) I'll need to add an optional property to widget that will give
the UI
designer more control on UI mirroring, but again, that's not part of the
whole
format design, that's just a minor detail.
In other words, I'm on it, but it'll be done in edje internally, if you
need/want
more details ask me. Of course, I will post here whenever I have something
interesting/big to ask/say.
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.
>
>
Sounds good.
> And that's all ! What's your opinion ?
>
Awesome.
--
Tom.
------------------------------------------------------------------------------
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-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
