On Sun, 09 Jan 2011 23:18:15 +0100 Fabian Nowak <timyst...@arcor.de> said:
hey ho. > when updating some German translation of e17 trunk, I noticed that many > components still lack i18n. So I started updating many of them and > successfully introduced translations as I could verify on my computer. > > As you may know, translations are an important step for software to be > spread and thereby debugged, tested, helped, enhanced and commented on > by a wide range of people from everywhere over the world. > > However, many questions have come up: > > 1. Why is gettext 0.14 used? 0.18 (and later?) does already exist. > (component e even uses 0.12.1) does it matter? why does it? > 2. What is the basic policy on internationalization with regard to > macros? I noticed several checks used seperately and differently within > the projects: > - #ifdef ENABLE_NLS > - #ifdef HAVE_GETTEXT no policy. ENABLE_NLS is newer, HAVE_GETTEXT is older. some things define both so both work. they are equivalent. :) > 3. Why is sometimes D_ as call to domain-gettext used, sometimes not? > Related, why is "PACKAGE dom" used (e/src/bin/e_intl.h) and sometimes > "PACKAGE" as domain? D_ (or d_) is for getting gettext messages FROM a specific domain - not just the package - but eg a module may have its own .po FOR its code - yes this seems off that the desktop translation strings are in the desktop file - a module may have no text at all thus not needing a .po - but it ALWAYS has a desktop file and a label in it thus its simpler to keep it in the desktop - saves extra complexity in modules that dont need it. anyway - package dom vs package simply changes the domain string from "a" "b" (or "ab" as c concatinates successive strings) or just as "a" 0 depends where the .po translations are meant to be. > 4. What is the policy wrt. the author in Makevars? Actually, it should > be the package author, and perhaps sometimes the maintainer instead. Makevars? > 5. Why are printfs in the main C files sometimes i18n'ed and sometimes > not? The information produced in there seems to be relevant to the user, if it goes into the gui - it should be translated. if its on stdout/err - it shouldnt. basically users dont see stdout/err - they never should. it's for "geeks and developers" only. you use a wm, or an app, and its stdout/err just go into nowhere. there is no point adding yet more stuff for translators to translate that normal users never see. think of it this way. when you buy a car - you get a "users manual/guide" and guess what - thats (normally) translated into several if not many languages. but the label on the underside of your car seat stating what material its made out of is in just 1 language - likely the native language of manufacture - or just english for universality. (i'm not going to get into discussions that some countries have regulations that say such labels must be in the local language etc. - this is just for illustration). labels a user is expected to encounter, see and use get translated. those they are not, don't get the treatment. it's left "in the universal lang" (and thats english for us). :) > hence it should be localized in any case, I think. Similar, some > components rather use INF(), ERR() or DBG(). It might make sense to > right declare these macros as translatable? there i disagree. as above. > 6. The gettext declarations are sometimes declared in main.h, sometimes > in C files, sometimes in package headers. Which one is the preferred > method? you mean #define _(x) gettext(x) ? as such its better in h files so it can be shared. > Summing up my questions, I would like to come up with the following > proposal: > > - Create a file similar to e/src/bin/e_intl.h t be installed to > $PREFIX/include and used in all components > - Containing > #ifdef ENABLE_NLS > # ifdef HAVE_GETTEXT > # include <libintl.h> // dunno whether this is really necessary > # define _(str) gettext(str) > # define d_(str, dom) dgettext(PACKAGE dom, str) > # define D_(str) dgettext(PACKAGE, str) > # else > # define _(str) (str) > # define d_(str, dom) (str) > # define D_(str) (str) > # endif > #endif can't do that unless we ALSO provide the gettext functions. the reason this is done per piece of software is that some systems.. dont have a gettext and the autoconf macros produce a version of gettext compiled into the app in that case. you cant provide headers that refer to functions that may not exist - unless we go providing them. unless you are just talking about e17 itself? in which case they have e_intl.h - and any modules for e can rely on this and use it. they should. > /* This macro is used to just mark string for translation, this is > * useful for string lists that are not dynamically allocated. > */ > #define N_(str) (str) > > - Then the E modules can use D_() as they already do, there is d_ (for > whatever reason), and the file can be included from all components > - Extend the macro definitions for INF, DBG and ERR to use _() > - Having this single, short include directive would alleviate the need > for discussion about where in a component to initiate the l10n. In most > cases, introducing real package headers, i.e. headers describing the > entire package in addition to config.h, if not already existent, might > be most senseful. > - I can do the work to make all components use gettext 0.18, use one > single i18n config wrt. Makevars, configure.ac, autogen.sh, C > directives. you'll have to explain what 0.18 is (compared to 0.12/0.14 etc.) and why? :) > I hope to achieve valuable discussion on the i18n / l10n issues. > > Fabian > > > > ------------------------------------------------------------------------------ > Gaining the trust of online customers is vital for the success of any company > that requires sensitive data to be transmitted over the Web. Learn how to > best implement a security strategy that keeps consumers' information secure > and instills the confidence they need to proceed with transactions. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > 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 ------------------------------------------------------------------------------ Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
