Re: [E-devel] Proposal on providing internationalization support for EDC TEXT

[Cedric B. <ced...@fr...>]

Hi,

On Fri, Mar 18, 2011 at 3:27 PM, Rajeev Ranjan <raj...@sa...> wrote:
> TEXT/TEXTBLOCK supports setting a string directly in edc.  So how to internationalize this string?

I will first point you to my old proposal that I didn't get time nor
urgency to do :
http://lists.enlightenment.fr/enlightenment-devel/2010/07/33748.html .
But I did have some more idea since then.

> We thought of few approaches. I am listing down them here.

> Approach  1:
>
>   Widgets/Applications based on elementary can use API edje_object_part_text_set(Evas_Object*<obj>, const char*<part_name>, const char* <string>); to set the text part by making use of I18N support of elementary(using gettext).
>
> Pros/Cons: This again depends in C Code, Theme extendibility is lost.

Yep, so a no go.

> Approach 2:
>
>   Having separate Attibutes to TEXT/TEXTBLOCK part for each of the languages being supported.
>
> e.g. text.text_enGB:"<string in english";
>
>  text_ko:"<string in korean"; and so on...
>
> Pros/Cons:  No reusability and makes the block definition bulky and complex.

Would also be incompatible with all translation tool.

> Approach 3:  Edje lib can do the translation with gettext package support.   TEXT/TEXTBLOCK can have additional  attribute pkg_name  to locate the gettext package.
>
> e.g. text.pkg_name: "edje";// package name in this example is elementary.
>
>  text.text: "string";

In fact, Edje file format already provide the possibility to do so.
Look inside edje/src/lib/edje_util.c in both functions edje_string_get
and edje_string_id_get. This is where this should be done imho. And
edje_cc parser should be extended by beeing able to handle _(String)
and automatically register this string in the internationalization
support.

> and PO files can be packed as part of EDJ.
>
> This approach will have backward compatibility with the existing edc files.

The problem with that solution is that it will not be included inside
the edje file and will break the nice one file to distribut and
install feature. It will also not take advantage of our full knowledge
of the string we need to translate at compile time. That means we do
not need to use a hash at runtime, but only an index in an array.

Now what is my current idea. It's easy : implement gettext like
interface in eet. Reason, not only edje will benefit from this
capability. For example you could add translation support to eyelight
easily if it was done at eet level.

So compared to my previous proposition, we will need to provide this
list of tools for eet :
- eet_xgettext will generate the .pot file from the Eet mapping information.
- eet_msgfmt will insert a .po inside an existing Eet section
("eet/localization/en_us") as an 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).
- eet_msgunfmt will extract a .po from an Eet file.
- eet_locale will display statistic of all translation of an Eet file.
- eet_locale_default will alias a translation to an Eet section (just
linking to "eet/localization/default")

Doing it with eet give us a lot of advantage, we could decide to
compress per language (so depending on what we need we can insert the
string in the eet_dictionnary or keep them compressed in an eet_data)
and accessing a string will be just a direct hit in an array (no need
to walk a hash). Of course it also preserve the main advantage,
delivering a compleltly self contained theme.

As I see it edje_cc parser (or eyelight parser) will do :
- request the internationalization context from eet (eet will create
it, if the file doesn't already have it)
- request an id that match a string (in both case, sting are static
stuff, so no need to handle plural form at this level), eet will also
add that string to the default locale array to.
- store the id in there own structure.
- close the internationalization context.

In edje_string_get, we will do something like that :
- if no locale open, request the right one from eet.
- request the string that match an id (eet will open the default map
if there is no translation and return the original string).
- hold a pointer to that string as it will not change after that.

When we do change the locale assigned to an edje object, we will just
need to wipeout all strings and let edje do the request when needed.

Handling plural is in my opinion not that much complex, but would be
just needed if we do plan to provide translation of string coming from
a lua or embryo script. I personnally think we should do it, so if I
have time to do it, I will do just that.

That make a fourth proposition, you can forget mine from July.
-- 
Cedric BAIL