forked from greenbone/gsa
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathi18n-howto.txt
173 lines (124 loc) · 6.01 KB
/
i18n-howto.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
GSA INTERNATIONALIZATION HOWTO
##############################
Requirements
============
In addition to the usual GSA requirements, the following are needed as well:
- msgmerge and xgettext (part of the GNU gettext tools)
- Python (scripts were tested with version 2.7.3)
- polib (Python gettext manipulation library)
If you are using a .po file editor, make sure it supports "msgctxt" and
plural forms correctly. (Some older editors may not.)
General notes
=============
- GSA uses UTF-8 text encoding, so you should use this for your translations
as well.
- Most GSA pages now use gettext for translations while the custom XML-based
format is no longer used. (See section "Migrating old XML translations" on
how to migrate translations using this format.)
- Help pages are translated separately. See "Translating help pages" for more.
- The locale codes used by GSA should be either
* an ISO 639 two-letter language code, like "de" for German
* an ISO 639 two-letter code followed "_" and an ISO 3166 country code, like
"pt_BR" for Brazilian Portuguese
Updating existing translations
==============================
To update existing translations using the gettext format follow these steps.
For old XML-based translations, see "Migrating old XML translations".
Summary
-------
1) Create new template files with
make gettext-pot
2) Merge the template with the .po files in the source directory
3) Edit the merged .po file
4) Copy the .po file back to the source directory, renaming as necessary
1 - Creating new template (.pot) files
--------------------------------------
To create a new template file simply run
make gettext-pot
which will generate the file and "gsad_js.pot" in the "src/po"
subdirectory of your build directory.
You can then use this as a template for your new translation or merge it with
existing translation files.
To only create a template file for the JavaScript you can also use the
make target "gettext-js-pot".
2 - Merge the template and existing translations
------------------------------------------------
a) Using a custom tool
To merge the template and existing translations with a tool other than the
basic pomerge you need to import / specify the following files:
- The .pot files generated in step 1
- The .po files from the "src/po" subdirectory of your GSA source directory.
b) Using make and pomerge
If your tool does not have its own functions for merging translation files,
you can use the following make target to merge the new .pot file with the
current .po files from the source directory:
make gettext-merge
This will generate "gsad_js-XX-merged.po"
files in the "src/po" subdirectory of your build directory,
with "XX" being a locale code as defined above in the section "General notes".
There is also a separate make target for JS .po files, gettext-js-merge.
3 - Update the translations
---------------------------
Next you can update the actual translations in the .po file.
If you want to edit the translations locally you can also copy them as
described in step 4 before editing them.
4 - Copying the new .po files
-----------------------------
The next step is to copy the files for your language back to "src/po" in the
source directory, naming the files "gsad_js-XX.po",
with "XX" again being the locale code.
As this means overwriting the old source .po file, you should verify the new
file is correct and/or backup the old file first.
Creating new translations for another locale
============================================
1 - Creating the template (.pot) file
-------------------------------------
The first step to a new translation is generating new template (.pot) files.
To do so, follow the first step under "Updating existing translations".
The destination file of the make target "gettext-pot" is "gsad_js.pot" in
the "src/po" subdirectory of your GSA build directory.
2 - Preparing the .po files
---------------------------
Next you have to use the generated files as templates for your new translation.
Once you are finished or want to install the in-progress translation for
testing, copy it to "src/po/gsad_js-XX.po" in your source directory with "XX"
being the locale code as defined above in the section "General notes".
3 - Setting up the installation
-------------------------------
In the file "CMakeLists.txt" in the "src/po" of your GSA source directory add an
additional line
MAKE_TRANSLATION (XX)
near the other MAKE_TRANSLATION (...) lines, with "XX" again being the
locale code.
Also add your language to the dependencies of the targets
"gettext-mo", "gettext-json" and "gettext-js-merge"
again replacing XX with the locale code:
add_custom_target (gettext-json
[...]
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/gsad-XX.json
[...])
add_custom_target (gettext-js-merge
[...]
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/gsad_js-XX-merged.po
[...])
Message Contexts
================
Some messages in GSA use the msgctxt to avoid ambiguity, for example if a
word like "login" could be used both as a noun or as a verb.
Unlike previous versions of GSA contexts are only used for this kind of
disambiguation.
Typical contexts and rules
--------------------------
* If a word or phrase can be used both as a verb and a noun, like "Login",
the verb should be given the context "Action Verb".
* If a string contains an adjective but not the corresponding noun, the implied
noun should be used as a context, e.g. "Active" should have the resource type
like "Note" as the context.
* Property names which may be ambiguous should have the resource type
or some kind of category as the context.
* Other ambiguous value should have the property name as context. If the
property name would also be ambiguous, a context as described in the previous
rule should be prepended followed by a "|", e.g. "Alert|Email"
* Some special contexts that may override some of the above:
- "Pagination" is used for strings on pagination controls like a "Next" page
button