Internationalization (for developers/authors)
Info
This page is only intended to be read by internationalization developers/authors. If you are a user who is interested in a localized SmartGit GUI, vote for smartgit.userecho.com/communities/1/topics/76-.
Note
If you want to help us to translate SmartGit to your language, please contact us at [email protected] (in English, please ).
Switching the SmartGit GUI to a certain locale
You can switch SmartGit to supported non-English locales in the Preferences, User Interface, Language.
Contributing translations
SmartGit translations are managed in the public repository https://github.com/syntevo/smartgit-translations. Contributing to translations happens in two ways:
- translating not yet translated texts from a language mapping file, like zh-CN/mapping_dev.zh_CN
- i18n development mode (translation changes are reread automatically)
Translating existing texts from language mapping files
This requires only minimal effort on your side, however you will not immediately benefit from your translations but you have to wait until they have been incorporated into the next SmartGit build.
- fork the smartgit-translations repository in GitHub
- apply your translations to zh-CN/mapping_dev.zh_CN
- send us a pull request to incorporate your translations
I18n development mode
This requires an initial setup effort but rewards you by seeing your translations immediately.
-
Fork the smartgit-translations repository in GitHub and get a local clone of your fork to your disk. For subsequent explanations, we assume the clone to be located in
D:\smartgit-translations
. -
To put SmartGit into i18n development mode, add following properties to smartgit.properties:
smartgit.i18n=<locale> smartgit.debug.i18n.development=<development-directory> smartgit.debug.i18n.master=<repo-root>/mapping
Replace
<locale>
by the locale you want to work with and set<development-directory>
to the appropriate locale’s sub-directory of the translation repository. For example:Example
smartgit.i18n=zh-CN smartgit.debug.i18n.development=D:/smartgit-translations/zh-CN smartgit.debug.i18n.master=D:/smartgit-translations/mapping
-
Exit and restart SmartGit
Layout of the development area
In i18n development mode following files will be created in the development directory:
mapping.<locale>
: the validated and reformatted version ofmapping_dev.<locale>
; it will be rewritten on every restart of SmartGit, and during the program run, too, if changes tomapping_dev.<locale>
have been detectedunmapped.<locale>
: mappings which are present in the master mapping file (smartgit.debug.i18n.master
) but which are not yet present inmapping.<locale>
unknown
: texts which have been detected at runtime but which are not yet present in the master mapping filemapping
: an extended version of the ‘master’ file which also contains newly detectedunknown
mappings
mapping_dev.<locale>
is the only file which you should edit.
All other files will be rewritten by SmartGit and thus changes will be lost!
Warning
The
mapping_dev.<locale>
will be reread by SmartGit when creating GUI elements, hence it will usually work well to modify and save this file, reopen a dialog or window and already see the results of the modification.
Content of a mapping file
Mapping files are basically key-value files, where the key represents a certain piece of text in SmartGit and the value represents its translation. Keys and values (translations) are separated by ‘=’. Keys may consist of prefixes, hard-coded constants and (dynamic) text which has been detected during runtime. (Dynamic) text will be enclosed in quotes.
Example
dlgSgCommit.btn"Commit"=提交
consists of the prefix
dlg
which denotes a dialog, the hard-coded constantSgCommit
which represents the Commit-Dialog, the prefixbtn
which denotes a button (in this dialog), and the detected (dynamic) text “Commit”. The translation for this key will be提交
.
There are also special mappings, called “macros” which are starting with ‘:’ and which can be thought of as “pre-processor” directives.
Macros will be used to substitute regular mapping values when writing the mapping.<locale>
file.
Example
:\*"Git-Flow"=Git工作流
will replace every “Git-Flow” text by “
Git工作流
” when writingmapping.<locale>
. Thus, following lines:wnd(Log|Project).mnu"Git-Flow"=Git-Flow wnd(Log|Project).tbr"Git-Flow"=Git-Flow
will turn to:
wnd(Log|Project).mnu"Git-Flow"=Git工作流 wnd(Log|Project).tbr"Git-Flow"=Git工作流
For keys, following meta characters are supported to create patterns which may match multiple ‘simple’ keys in SmartGit:
\
- escape character to escape itself or other meta characters*
- match zero or more characters$
- variable start(,),|
- “or”-group%
- variable count[,],{,}
- reserved, but not yet used
For values (=translations), following meta characters are supported:
$
- variable start
The wildcard match (*
) is expensier to process and for regular mappings should only be used for a very small amount of keys, like “OK”-Buttons.
It’s fine and even encouraged to use *
within macros.
Actually, the *
is even the reason why macros exist: instead of having many *
-patterns at runtime which are expensive to process for SmartGit (for every user running SmartGit), the expensive matching is done at translation development time (only once per developer).
Variables are of the form $1
, $2
, … and can be used to match a piece of text in the key and substitute the corresponding variable in the translation by this text.
Example
dlgSgSvnClientCertificate.wrn"Authentication to the SVN repository '$1' failed with error: $2"= 对SVN版本库'$1'的身份验证失败,错误:$2'
For certain, unique keys, the matching happens indirectly by using the master mapping.
This allows to skip the dynamic text part from the key.
Still it’s necessary to declare the variables used in the mapped translation and this is where %
will be used.
Example
dlgQProxyConnectionFailed.hdl%1=无法连接到 $1.
“or”-groups are used to summarize identical translations for a set of keys.
Example
wnd(Log|Project|Compare|ConflictSolver).mniWindow-fullScreen=全屏
If a special character needs to be used literally in a key or value, it has to be escaped using \
.
Example
wnd(Log|Project).tab"Changes of $1 - $2"=$1 的变化 - $2 wnd(Log|Project).tab"Changes of $1 - $2 \($3\)"=\ $1 的变化 - $2 \($3\) wnd(Log|Project).tab"Changes of $1 \($2\) - $3"=\ $1 的变化\($2\) - $3 wnd(Log|Project).tab"Changes of $1 \($2\)"=$1 的变化\($2\) wnd(Log|Project).tab"Changes"=的变化
are the translations of the various forms of the ‘Changes’ tab title in the Log window.
For long mappings, \
after the =
-separator can be used to wrap the mapping.
Tip
If SmartGit suddenly fails to pick up modifications of the mapping file, this may be caused by invalid/unparsable lines. In this case try to restart SmartGit. If anything is wrong with the mapping file, SmartGit won’t start up and a corresponding error message is logged to
logs/log.txt.0
in the Settings directory.
Contributing changes to language mapping files
To contribute your changes to a language mapping file:
- setup SmartGit as explained above (we assume your repository located at
<repo>
and your development directory located at<dev>
) - apply your changes to
<dev>/mapping_dev.<locale>
- test the changes
- wait until SmartGit has rewritten
<dev>/mapping_dev.<locale>
to<dev>/mapping.<locale>
(as long as you stick to the formatting rules, these files should be identical now) - copy
<dev>/mapping.<locale>
over to<dev>/mapping_dev.<locale>
(to continue your work with the reformatted version) - commit and push your changes of
<dev\>/mapping_dev.<locale>
to your GitHub fork - send us a pull request
Contributing changes to the master mapping
While SmartGit is in i18n development mode, it will collect not yet known text pieces in the unknown
file.
This is what we are doing ourselves during SmartGit development and which serves as foundation for extending the master mapping
file (see above).
Contributing changes to this file is similar to language mapping files:
- setup SmartGit as explained above (we assume your repository located at
<repo>
and your development directory located at<dev>
) - use SmartGit to collect new changes in
<dev>/unknown
; these changes will at the same time be combined with known changes and written to<dev>/mapping
- copy
<dev>/
mapping over to<repo>/mapping
(this is the versioned file in the translations repository) - review changes to
<repo>/m
apping using Git’s diff (e.g. in the Changes view in SmartGit) - tricky part: in
<repo>/mapping
try to figure out which of the changes are static and which are dynamic text and replace the dynamic text- by variables ($) in key and value if the key actually contains the dynamic text in quotes
-
by variable count (%) in key and variable ($) in value if the key does not contain the dynamic text (i.e. if there are no quotes)
Tip
Usually, it’s a good idea to trigger the display of the text with dynamic content in a way that the dynamic content changes (e.g. by applying a certain operation to two different branches or commits). This way, SmartGit will log both text pieces (which only differ in the dynamic part) to
unknown
and it will become easy to join these separate lines into one line by substituting with variables.
- exit SmartGit
- get rid of the those lines from
<dev>/unknown
which you have processed - restart SmartGit
- immediately after starting up, SmartGit should rewrite the
<dev>/mapping
file from your updated<repo>/mapping
and the reduced<dev>/unknown
file - continue working with SmartGit and retrigger the operation for which you have extended the
mapping
file with even different dynamic content; now SmartGit should not add anymore lines to<dev>/unknown
(check this) - commit and push your changes of
<repo>/mapping
to your GitHub fork - send us a pull request
We will review your pull request and apply, or ask for further changes related to static-vs-dynamic texts.