Changes between Version 2 and Version 3 of TranslationsAndStringFreezes

Timestamp:

May 27, 2018, 3:44:45 PM (6 years ago)

Author:

John Bailey

Comment:

Some minor tweaking here.

TranslationsAndStringFreezes

@@ -3 +3 @@
 
 == How Does It Work? ==
-Within our source code and interface designs, we have strings that are displayed to the user.  They can be anything from "Manage Accounts" to "Extended Away" to "Quit".  These user-visible strings are "marked" for translation.  That is to say that we mark within the source code and interface designs that the given text should be translated.  Using the appropriate tools with the gettext library, a translation template, known as a "pot" file, is generated.  Someone who wishes to translate Pidgin into another language will take the translation template, name it appropriately for the language of his/her choice and review each string in the file, entering the correctly translated text for that language into the file.  Once completed, the translator submits the translation to us.  (See TipsForTranslators for specific details.)  The completed translations are "compiled" into the format needed by gettext at runtime, and the appropriate file is loaded when Pidgin is launched in a given language.  Each time text needs to be displayed, gettext uses the text we specified to determine the correct translated text to display and uses it instead.  (Any text that isn't translated will simply show the English text we originally specified so that Pidgin functions.)
+Within our source code and interface designs, we have strings that are displayed to the user.  They can be anything from "Manage Accounts" to "Extended Away" to "Quit".  These user-visible strings are "marked" for translation.  That is to say that we mark within the source code and interface designs that the given text should be translated.  Using the appropriate tools with the gettext library, a translation template, known as a "`pot`" file, is generated.  Someone who wishes to translate Pidgin into another language will take the translation template, name it appropriately for the language of his/her choice (for example, `en_GB.po` for British English) and review each string in the file, entering the correctly translated text for that language into the file.  Once completed, the translator submits the translation to us.  (See TipsForTranslators for specific details.)  When Pidgin is compiled from its source code to produce the executable program you run, the completed translations are "compiled" into the format gettext needs ("`gmo`" files), and the appropriate file is loaded when Pidgin is launched in a given language.  For example, running Pidgin in Brazilian Portugese would cause gettext to load `pt_BR.gmo` from our set of translations.  Each time text needs to be displayed, gettext uses the text we specified to determine the correct translated text to display and uses it instead.  (Any text that isn't translated will simply show the English text we originally specified so that Pidgin functions.)
 
 == String Freezes ==
 During the Pidgin development cycle, we'll call for a string freeze close to release.  A string freeze means that no user-visible strings are allowed to be added or changed until the release is made.  This allows the translators time to translate any new strings and revise their existing translations if they feel the need to do so.  The string freeze means that all text specified in the code and designs are final for the release currently being worked on, even if there is a spelling or grammar mistake or some other problem in one or more strings.
 
-Typically a string freeze will last for a week, as there usually aren't many changes that would require existing translators' attention.  Occasionally a longer freeze will be required if there are significant changes--usually two weeks are enough in these cases.  However, huge changes, like Pidgin 3.0.0 will be when we are ready to look at releasing it, will require significantly more time investment from our translators.  A string freeze of a month could be implemented to give translators enough time to update translations appropriately.  Or, alternatively, multiple shorter string freezes could be done throughout the development cycle to reduce the overall burden of maintaining the translations.
+Typically a string freeze will last for a week, as there usually aren't many changes that would require existing translators' attention.  Occasionally a longer freeze will be required if there are larger changes--usually two weeks are enough in these cases.  However, huge changes, like Pidgin 3.0.0 will be when we are ready to look at releasing it, will require significantly more time investment from our translators.  A string freeze of a month could be implemented to give translators enough time to update translations appropriately.  Or, alternatively, multiple shorter string freezes could be done throughout the development cycle to reduce the overall burden of maintaining the translations.