On Fri, 9 Jul 2010 18:57:49 +0200 Cedric BAIL <cedric.b...@free.fr> said:
hmm - ok. i see positives of re-using po's but there are also downsides. like
simply not being like the rest of the edc stuff. but that aside. beware the
simplicity of what you THINK you are doing. or the lack of simplicity.
printf("we have %s cows\n", cows);
printf("he came %th in the race\n", position);
now just take these example and do it for all languages. (the above will
actually barf without translations, but with.. deciding where to go from "1
cow" to "2 cows" is entirely language based - english happens to change between
1 and 2, most european languages do, but... just start reading up on all
languages. the "4th in the race" vs "3rd in the race" vs "2nd in the race"
etc. etc.... same applies for all languages. yes - this is needed because
labels are not always static. some embryo (or lua) may need to generate them
from state. and you cant feasibly have this script/code know about every
langauge and its plurality or positioning rules etc. hell even word order may
change between possible inputs.
so... before you open this can of worms... i suggest you have a read of pages
like this:
http://www.gnu.org/software/hello/manual/gettext/Plural-forms.html
i can go on about other languages - like asian ones (particularly japanese and
i think korean too) where the above is neever a problem BUT if you do
printf("there are %i %s in the room", object, count);
where object is a string. it may be "glass" or "glasses" or "chicken" or
"chickens" - but... how you write the number varies depending on the item being
counted. example:
1 == ichi
2 == ni
3 == sam
beer == biru
rabbit == usagi
1 beer == ippai biru
2 beers == nihai biru
3 beers = sambai biru
1 rabbit == ihiki usagi
2 rabbits == nihiki usagi
3 rabbits == sambiki usagi
(and there is a generic counter -> hitotsu, futatsu, mittsu... that you can use
for anything but it's not "good japanese" to use it when you should use a
specific one). days of the month are a complete shambles as the majority are
special case too.
anyway... the principle holds - that languages have wild and various
conventions of doing the above, and any translation system needs to be able to
deal with this in the end. translation is NOT a simple string replace. and we
are only talking translation here. not localization. localization is the
flipping of the ui, changing icons so they are more meaningful to the local
culture, colors and more. still just covering translating text correctly. :)
(sorry to throw a wet blanket onto it all :))
> 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-devel mailing list
> enlightenment-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
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
