On Fri, 18 Mar 2011 19:57:16 +0530 Rajeev Ranjan <rajee...@samsung.com> said:

ok. right now.. approach 1 is what is done because po's and text comes FROM the
app. they define label contents etc. etc.

approach 2 is a bit much... but approach 3 doesnt solve a problem.

i'm a designer. i design an edje and ADD an extra bit of text in my design. how
will that be translated? the translation files simply wont have that content
and it will remain untranslated. only way i can do this is to ship translations
inside the edj file, so you need to use #2 for that - or something like it
(embed a po.gmo into the edj file and be able to use it).

the problem here is you have strings coming from not just 1 source (app) but
MULTIPLE sources now (app PLUS 1 or more edje files that can be replaced at
runtime). that means strings can be added or changed in their source form.

unless we start to accept that translation will never fully work - in which
case... #1 is already the solution. all text in the edje gets eventually set by
the user (the app or library) and thus it determines the translation. the
alternative is to have "might not always work" translations that have edje use
1 or MORE packages (i'd argue it should have fallbacks - an app specific
package then fall back to 1 or more system installed translation packages that
can translate generic strings like "OK" and "Cancel" etc. if we are now
accepting that this will never be totally correct anyway).

> Hi,
> 
>  
> 
> TEXT/TEXTBLOCK supports setting a string directly in edc.  So how to
> internationalize this string?
> 
>  
> 
> 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.
> 
>  
> 
> 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.
> 
>  
> 
> 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";
> 
>  
> 
> and PO files can be packed as part of EDJ.
> 
> This approach will have backward compatibility with the existing edc files.
> 
>  
> 
> Appreciate your valuable comments.
> 
>  
> 
> Thank You.
> 
> Regards,
> 
> Rajeev
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@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


------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to