← Back to branch summary

~svn/ubuntu/oneiric/subversion/ppa

« back to all changes in this revision

Viewing changes to notes/l10n-problems

  • Committer: Bazaar Package Importer
  • Author(s): Adam Conrad
  • Date: 2005-12-05 01:26:14 UTC
  • mfrom: (1.1.2 upstream)
  • Revision ID: james.westby@ubuntu.com-20051205012614-qom4xfypgtsqc2xq
Tags: 1.2.3dfsg1-3ubuntu1
Merge with the final Debian release of 1.2.3dfsg1-3, bringing in
fixes to the clean target, better documentation of the libdb4.3
upgrade and build fixes to work with swig1.3_1.3.27.

Show diffs side-by-side

added added

removed removed

Lines of Context:
notes/l10n-problems
 
1
 
 
2
 
 
3
Issues (and their resolutions) when using gettext for message translation
 
4
 
 
5
 
 
6
Contents
 
7
========
 
8
 
 
9
 * Windows issues
 
10
 * Automatic characterset conversion
 
11
 * Translations on the client
 
12
 * No translations on the server
 
13
 * Translating plural forms (ngettext() support)
 
14
 
 
15
 
 
16
 
 
17
Windows issues
 
18
==============
 
19
 
 
20
On Windows, Subversion is linked against a modified version of GNU gettext.
 
21
This resolves several issues:
 
22
 
 
23
 - Eliminated need to link against libiconv (which would be the second
 
24
   iconv library, since we already link against apr-iconv)
 
25
 - No automatic charset conversion (guaranteed UTF-8 strings returned by
 
26
   gettext() calls without performance penalties)
 
27
 
 
28
more in the paragraphs below...
 
29
 
 
30
 
 
31
Automatic characterset conversion
 
32
=================================
 
33
 
 
34
Some gettext implementations automatically convert the strings in the
 
35
message catalogue to the active system characterset.  The source encoding
 
36
is stored in the "" message id.  The message string looks somewhat like
 
37
a mime header and contains a "Content-Encoding" line. It's typically GNU's
 
38
gettext which does this.
 
39
 
 
40
Subversion uses UTF-8 to encode strings internally, which may not be the
 
41
systems default character encoding.  To prevent internal corruption,
 
42
libsvn_subr:svn_cmdline_init2() explicitly tells gettext to return UTF-8
 
43
encoded strings if it has bind_textdomain_codeset().
 
44
 
 
45
Some gettext implementations don't contain automatic string recoding.  In
 
46
order to work with both recoding and non-recoding implementations, the
 
47
source strings must be UTF-8 encoded.  This is achieved by requiring .po
 
48
files to be UTF-8 encoded.  [Note: a pre-commit hook has been installed to
 
49
ensure this.]
 
50
 
 
51
On Windows Subversion links against a version of GNU gettext, which has
 
52
been modified not to do character conversions.  This eliminates the
 
53
requirement to link against libiconv which would mean Subversion being
 
54
linked against 2 iconv libraries (apr_iconv as well as libiconv).
 
55
 
 
56
 
 
57
Translations on the client
 
58
==========================
 
59
 
 
60
The translation effort is to translate all error messages generated on
 
61
the system on which the user has invoked his subversion command (svnadmin,
 
62
svnlook, svndumpfilter, svnversion or svn).
 
63
 
 
64
This means that in all layers of the libraries strings have been marked for
 
65
translation, either with _() or N_().
 
66
 
 
67
Parameters are sprintf-ed straight into errorstrings at the time they are
 
68
added to the error structure, so most strings are marked with _() and
 
69
translated directly into the language for which the client was set up.
 
70
[Note: The N_() macro markes strings for delayed translation.]
 
71
 
 
72
 
 
73
 
 
74
Translations on the server
 
75
==========================
 
76
 
 
77
On systems which define the LC_MESSAGES constant, setlocale() can be used
 
78
to set string translation for all (error) strings even those outside
 
79
the Subversion domain.
 
80
 
 
81
Windows doesn't define LC_MESSAGES.  Instead GNU gettext uses the environ-
 
82
ment variables LANGUAGE, LC_ALL, LC_MESSAGES and LANG (in that order) to
 
83
find out what language to translate to.  If none of these are defined, the
 
84
system and user default locales are queried.
 
85
 
 
86
While systems which have the LC_MESSAGES flag (or setenv() - of which
 
87
Windows has neither) allow languages to be switched at run time, this cannot
 
88
be done portably.
 
89
 
 
90
Any attempt to use setlocale() in an Apache environment will conflict with
 
91
settings other modules expect to be setup.  On the svnserve side having no
 
92
portable way to change languages dynamically, means that the environment
 
93
has to be set up correctly from the start.
 
94
 
 
95
In other words, there is no way - programmatically - to ensure that messages
 
96
are served in any specific language.
 
97
 
 
98
Note: Original consensus indicated that translation of messages at the
 
99
server side should stay untranslated for transmission to the client. Client
 
100
side translation is not an option, because by then the parameter values
 
101
have been inserted into the string meaning that it can't be looked up in the
 
102
messages catalogue anymore.
 
103
 
 
104
 
 
105
 
 
106
Translating plural forms (ngettext() support)
 
107
=============================================
 
108
 
 
109
The code below works in english and can be translated to a number of
 
110
languages.  However in some languages more than 2 forms are required
 
111
to do a correct translation.  The ngettext() function takes care of
 
112
grabbing the right translation for those languages.  Unfortunately,
 
113
the function is a GNU extention and thus non-portable.
 
114
 
 
115
  message = (n > 1) ? _("1 File found") :
 
116
                      apr_sprintf (pool, _("%d Files found"), n);
 
117
 
 
118
Because of this limitation, some strings in the client have not been
 
119
marked for translation.
 
120
 
 
121
*** We're looking for good suggestions to work around this.