On Friday 26 August 2005 21:58, Rowan Collins wrote:
On 26/08/05, Sabine Cretella sabine_cretella@yahoo.it wrote:
The easiest thing is to use a CAT-Tool to translate the UI and then put the translation memory (tmx) at disposal - so anyone who does an update will have 100% matches from the old UI and the rest needs to be translated. This way the translator goes also over the correction of eventual misspellings or changes in terminology are possible in order to have an even better product.
One of the big problems with the current setup is that the MediaWiki: namespace (the "live" messages in the database of a particular project) are used both for localisation and customisation - so whenever you export the messages from, say, Wikipedia, you have to work out which changes are due to changes in the software, which are cosmetic but appropriate for application to other projects, and which are specific to the particular project. This is probably the biggest challenge which any new l10n system (or even a new approach to i18n) needs to address.
Maybe it would be possible to make a list of strings which are expected to be customised, and which are not. For example, "From Wikipedia, the free encyclopedia" will always be customised while "Article", "Discussion", "Edit", "Recent Changes"... will never be. Then, LanguageXx.php could periodically be refreshed with only "safe" strings filled in. Language files for Navajo and other languages which only have translations in MediaWiki namespace could be created from scratch in this way.