[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

message translation server side (was: svn commit: r13271 - trunk/notes)

From: Erik Hülsmann <e.huelsmann_at_gmx.net>
Date: 2005-03-12 22:26:26 CET
('binary' encoding is not supported, stored as-is) >Author: dionisos
>Date: Sat Mar 5 15:11:07 2005
>New Revision: 13271
> trunk/notes/l10n-problems
>Describe the problems we have overcome (or still have) with message
>* notes/l10n-problems: New. Currently describes problems with message
> translating, but others can be addet if needed.
>Added: trunk/notes/l10n-problems
>Url: http://svn.collab.net/viewcvs/svn/trunk/notes/l10n-problems?view=auto&rev=13271
>--- (empty file)
>+++ trunk/notes/l10n-problems Sat Mar 5 15:11:07 2005
>@@ -0,0 +1,121 @@
>+Issues (and their resolutions) when using gettext for message translation
>+ * Windows issues
>+ * Automatic characterset conversion
>+ * Translations on the client
>+ * No translations on the server
>+ * Translating plural forms (ngettext() support)

[ snip ]

>+Translations on the server
>+On systems which define the LC_MESSAGES constant, setlocale() can be used
>+to set string translation for all (error) strings even those outside
>+the Subversion domain.
>+Windows doesn't define LC_MESSAGES. Instead GNU gettext uses the environ-
>+ment variables LANGUAGE, LC_ALL, LC_MESSAGES and LANG (in that order) to
>+find out what language to translate to. If none of these are defined, the
>+system and user default locales are queried.
>+While systems which have the LC_MESSAGES flag (or setenv() - of which
>+Windows has neither) allow languages to be switched at run time, this cannot
>+be done portably.
>+Any attempt to use setlocale() in an Apache environment will conflict with
>+settings other modules expect to be setup. On the svnserve side having no
>+portable way to change languages dynamically, means that the environment
>+has to be set up correctly from the start.
>+In other words, there is no way - programmatically - to ensure that messages
>+are served in any specific language.
>+Note: Original consensus indicated that translation of messages at the
>+server side should stay untranslated for transmission to the client. Client
>+side translation is not an option, because by then the parameter values
>+have been inserted into the string meaning that it can't be looked up in the
>+messages catalogue anymore.

I think the above indicates I should revert r13182 *and* have to translate any
messages which remain untranslated after that. Also, I think that we can keep
switching LC_MESSAGES back to "C" on systems which define it. The large FIXME
by lundblad which I deleted in that commit can be replaced by something
pointing to this document.

Also, on systems which don't define LC_MESSAGES, svnserve (or Apache) must be
started in an environment which prevents message translation in order to get
untranslated messages on the client. I think we have to document this in the
book or the man page / help output for svnserve.




To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 12 22:27:35 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.