('binary' encoding is not supported, stored as-is)
>Author: dionisos
>Date: Sat Mar 5 15:11:07 2005
>New Revision: 13271
>
>Added:
> trunk/notes/l10n-problems
>Log:
>Describe the problems we have overcome (or still have) with message
>translating.
>
>* 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
>+
>+
>+Contents
>+========
>+
>+ * 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.
Comments?
bye,
Erik.
---------------------------------------------------------------------
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