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
