|
|
| Line 46: |
Line 46: |
| ** Short project life-cycle: localization requirements should not be complex | | ** Short project life-cycle: localization requirements should not be complex |
| ** Long project life-cycle: use techniques to make updating the site much easier | | ** Long project life-cycle: use techniques to make updating the site much easier |
|
| |
| == Download Day, a case-study ==
| |
|
| |
| In the above Gettext example, notice how the web developer used "certificate_intro" as the value of the msgid. This is not the actual content that was translated. So, if a localizer wanted to use one of the many powerful Gettext tools, like po-editor, the msgid provides NO CONTEXT for translation or for other localizers to verify translations when QA-ing. This should have been avoided.
| |
|
| |
| In the case of Download Day, someone created entity-like identifiers in the msgid, which we have shown above with the "certificate_intro" key. Then, an en-US repository was created holding the translations to all the entity-like values of msgid. This is very non-standard because it avoids one of the obvious powers of Gettext. When English content is used as the value of the msgid, there is no need to place that content in a special repository.
| |
|
| |
| But, in the Download Day example, when changes were made to en-US, the web-developer had to push those changes to all the repositories of all the locales. Localizers had to revisit an en-US repository to find the exact msgid, review the change, and return to their repository to make changes.
| |
|
| |
| Without having the exact content as the msgid, this process may cause several errors since the localizers cannot has to continually switch back-and-forth. In this case, the choice to use customized values for msgid was error-prone, onerous, and unfamiliar to localizers who are used to more customary Gettext operations.
| |
|
| |
| For more, please review this wikipedia article on [http://en.wikipedia.org/wiki/Gettext Gettext].
| |