通過國際化來開始¶
有個專案，並想要將其翻譯為幾種語言？這個指南會幫您進行。幾種典型的情況展示出來，而多數範例是通用的，並且也可以用於其它情景。
Before translating any software, you should realize that languages around the world are really different and you should not make any assumption based on your experience. For most of languages it will look weird if you try to concatenate a sentence out of translated segments. You also should properly handle plural forms because many languages have complex rules for that and the internationalization framework you end up using should support this.
Last but not least, sometimes it might be necessary to add some context to the
translated string. Imagine a translator would get string Sun to translate.
Without context most people would translate that as our closest star, but it
might be actually used as an abbreviation for Sunday.
選擇國家化框架¶
選擇您的平臺上任何標準化的，嘗試通過建立自己的框架來處理在地化，來避免重新發明輪子。 Weblate 支援大多數廣泛使用的框架，更多資訊請參閱 在地化檔案格式 （特別是 翻譯類型功能 ）。
我們對一些平臺的個人推薦在下面的表格中。這基於我們的經驗，但這無法覆寫所有的使用情況，因此做選擇時總是要考慮您的環境。
平臺 |
推薦的格式 |
|---|---|
Android |
|
iOS |
|
Qt |
|
Python |
|
PHP |
|
C/C++ |
|
C# |
|
Perl |
|
Ruby |
|
Web 擴充 |
|
Java |
|
JavaScript |
一些格式更具體的工作流程在後面的章節中描述：
也參考
Educating developers for proper internationalization¶
Software internationalization is not just about being able to translate strings but about making the whole software look native to a user from another country. This also includes things like date or number formatting, currency display, or inputting text in the right direction. Most software frameworks have good support for this, so please follow their instructions for all these areas.
The string translation might not be a straightforward task as well. This is especially true for short strings like captions or button labels. Different languages have different rules, and it is not reasonable to expect that the same string will always be translated the same. In many situations it also might not be clear how to translate, and it is even challenging to distinguish whether the word is a verb or a noun.
All developers should understand this and uniquely identify strings used in
different scopes. For example, None meaning "no users" might be translated
differently from None meaning "no items". Use different keys or contexts to
distinguish these terms for translators. You can provide additional context in
Weblate, such as Screenshots and visual context or 解釋.
The technical side is only part of the work. Translators also notice the project workflow around strings, releases, and communication. A few practices make collaboration much easier:
Respond to translator questions and comments, and make sure the advertised contact channel is actually monitored.
Avoid unnecessary churn in source strings. Rewording or replacing existing strings without a user-visible reason creates avoidable translation work.
Add enough context for translators to understand short or ambiguous strings. Avoid concatenating sentences from fragments, use placeholders that can be reordered, and rely on built-in plural handling.
Ship translations regularly so completed work does not stay unused in Weblate for long periods.
Communicate workflow or policy changes, and keep contribution requirements realistic for smaller language teams.
If a project is no longer maintained, reflect that in the translation workflow instead of leaving components open indefinitely.
Weblate can help with some of these issues. In particular, regular automatic commits from Weblate make translation progress visible in the source code history and reduce the risk that finished work is forgotten before a release. See 持續在地化 for automation options.
也參考