Vladimir Gorr wrote: Have you looked at the patch I've sent? It doesn't use gettext. It just proposes the way to move forward towards propertly localized DRLVM. I think we will be able to use ICU4C java-like localization in the following way: * extract localizable strings from .cpp files using xgettext * process resulting .po files and autogenerate resource bundles from them * use resource bundles for translation and distribution
> There is an essential obstacle to use the *gettext* approach. > It's impossible to run VM on Windows platform if not to take into account > CYGWIN environment. I do not insist on using gettext, but will answer just for the record: there exists a project to port libintl to native Windows using MinGW [1] > I'm not clear as well how we will merge the previous .po catalogs (already > translated) with new ones (when new strings to be added). Again, I do not insist on using gettext, however, gettext has the tool exactly for this task: msgmerge [2] > However _() should be inserted for all strings (and then deleted?) to > achieve this. It involves too big efforts. The effort could be big, but is needed for any localization system we use. The task to classify the messages to translatable (visible to user on a day-to-day basis) and non-translatable (internal errors and debug logging) is needed anyway, because we do not want to overload translators with useless work of translating every string in the project. IMHO, _() marker is visually the prettiest way mark localizable strings. (compared to "// NON-NLS" comments and resource bundle constants) > Therefore my preference is to use more universal approach, namely, ICU4C or > LOG4CXX or combination of them. I've looked through Log4cxx manual and haven't found anything concerning both localization and internationalization. By the way, DRLVM already uses Log4cxx. ICU4C provides both internationalization and localization services [3]. It's native system uses ResourceBundles and looks similar to Java localization system, and it suffers from the same drawback: the message keys are constants, which are never printed, but have to be defined and referenced in multiple places. The developer overhead to make a localizable message is as high as * define a new constant in some file * add a message to the default resource bundle and inolves editing multiple files. I have no doubt that this overhead significantly higher than putting three characters to mark the string in _() way. -- Salikh. [1] http://gnuwin32.sourceforge.net/packages/libintl.htm [2] http://www.gnu.org/software/gettext/manual/html_mono/gettext.html#SEC36 [3] http://icu.sourceforge.net/userguide/localizing.html --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
