Hey all, 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) 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 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? 4. What is the policy wrt. the author in Makevars? Actually, it should be the package author, and perhaps sometimes the maintainer instead. 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, 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? 6. The gettext declarations are sometimes declared in main.h, sometimes in C files, sometimes in package headers. Which one is the preferred method? 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 /* 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. 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
