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 ?
--
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
