On Friday 26 August 2005 21:58, Rowan Collins wrote:
On 26/08/05, Sabine Cretella
<sabine_cretella(a)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.