написане Tue, 18 Oct 2011 14:11:33 +0300, Romain d'Alverny
<[email protected]>:
Hi,
sorry for the delay, I just saw the point in last Council meeting
notes about this.
On Thu, Oct 13, 2011 at 20:27, Yuri Chornoivan <[email protected]> wrote:
I just wanted to propose to use Translate extension on it. It is now
successfully used on KDE UserBase:
http://userbase.kde.org/Welcome_to_KDE_UserBase and TechBase
Advantages of this extension as well as the contact information of
authors
can be found here:
http://www.mediawiki.org/wiki/Extension:Translate
This extension can significantly ease up maintenance of the translations
with no additional efforts to sync translations with original (automatic
synchronization).
Actually, we didn't plan to manage l10n that way, but by having
distinct wiki instances per locale (wiki.mageia.org/en/,
wiki.mageia.org/fr/ and so on) and interwiki-link them. The same way
Wikipedia does it actually (and we used to at MDV as well).
So using this extension means a significant change in how we lay things
out.
I guess each solution has its own benefit, so how would these compare?
If it is planned to have just several static pages which will be
translatable (no changes, one time translation, announcement for every new
translatable pages) the old approach is good enough. But I have an
impression that this is not the case.
The old-style translation process [1], [2] implies one of the following
options:
1. Translator just copy and paste the content from the original page and
translate it (inter-wiki links will be established by the bot)
2. Translator should make some modification of the original page to make
the translation visible then copy the content and translate it
There are several shortcomings in this approach:
1. It is hard to find all the pages that are worth translating (the list
should be maintained manually)
2. It is easy to begin the translation of incomplete pages under
construction or outdated pages
3. It is not easy to begin translation [1], [2]
4. It is hard to track the changes (you should subscribe on the page feed
or add it to the watch list to get notified)
5. It is hard to maintain the translation (usually you should guess about
the part of the translation to be changed in view of the original changes)
6. It is hard to know that the translation is outdated
7. It is hard to keep the coherence of the core documentation (isn't it be
good to have manuals on distribution collected on install CD with major
translations converted from wiki and 100% coherent?)
Translate extension allows to avoid these problems:
1. All translatable pages are collected in one list (e.g. [3]).
2. Every team can have its own untranslatable pages (e.g. [4]). All pages
are separated by the team domains (/<language_code>, e.g. "/fr") and team
categories.
3. Pages can be added or removed from translation by the wiki admins.
Translation of the pages, which are not marked for translation is
prohibited.
4. To begin translation just register, ask to be added to the translators
group and push "Translate the page" or the corresponding link in the list
of pages.
5. Changes are tracked automatically. The extension shows the changes in
every module with colors.
6. Automatic maintenance of the translations. All unchanged parts are
kept, all changed are marked as fuzzy.
7. Every outdated block is marked with red (e.g. [5]).
8. As all the complete translations are semantically same (extension has
its own embedded QA) they can be exported as docbook with localized
screenshots in docbook format (e.g. [6]). Docbook can be easily converted
to html, pdf, etc.
[1]
http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Translation_Quick_Start_Guide/sect-Translation_Quick_Start_Guide-Translating_Wiki.html
[2] http://wiki.ubuntu-women.org/HowToTranslateWiki
[3]
http://userbase.kde.org/index.php?title=Special%3ALanguageStats&code=de&suppresscomplete=1
[4] http://userbase.kde.org/Translation_Workflow/Ukrainian
[5] http://userbase.kde.org/Krita/de
[6] http://userbase.kde.org/How_To_Convert_a_UserBase_Manual_to_Docbook
