Translating:KDE

We are considering investing in making translation of KDE possible in translatewiki.net for the KDE teams that want it. We need help to make that happen: if you are involved in KDE translation or would like to translate KDE at translatewiki.net, please sign up here and leave comments on the talk page if you have any concerns, questions or suggestions.

To start, we need at least a couple of KDE translation teams for the respective languages asking to use translatewiki.net, and support from KDE folks for things like commit access. User:Nike has submitted a talk proposal for Akademy 2013, where this idea will be discussed. The plan is to start with some pilot languages during Akademy and add more languages after remaining issues are solved and when there is interest from their translators.

I want to translate KDE here

• (Finnish) --Nike (talk) 17:21, 15 March 2013 (UTC)
• (Finnish) --Jessej (talk) 07:38, 16 March 2013 (UTC)
• (Finnish) --Lliehu (talk) 23:14, 19 March 2013 (UTC)
• (Greek) --Yannis A ^✆|☑
• (Greek) --Konqoro (talk) 18:45, 17 March 2013 (UTC)
• (Slovene) --Miha (talk) 18:59, 15 March 2013 (UTC)
• (Sinhala) -- Pasindu ^{(✉ • ✐ • ✍)} 12:16, 16 March 2013 (UTC)
• (Malay) -- Anakmalaysia (talk) 15:46, 16 March 2013 (UTC)
• (Esperanto) --★ → Airon  16:29, 16 March 2013 (UTC)
• (Esperanto) --KuboF (talk) 17:22, 9 July 2013 (UTC)
• (French) -- Peter17 (talk) 16:42, 18 March 2013 (UTC)
• (Marathi) --Ogdhekne (talk) 20:54, 23 March 2013 (UTC)
• (Colognian) --Purodha Blissenbach (talk) 00:53, 26 March 2013 (UTC)
• (Telugu) ----Malkum (talk) 22:50, 7 April 2013 (UTC)
• (Slovak) --Wizzard (talk) 18:41, 27 September 2013 (UTC)
• Your name and language(s)

I want to help to make this happen

• --Nike (talk) 17:21, 15 March 2013 (UTC)
• --Nemo (talk) 17:28, 15 March 2013 (UTC)
• --Miha (talk) 19:00, 15 March 2013 (UTC)
• -- Pasindu ^{(✉ • ✐ • ✍)} 12:17, 16 March 2013 (UTC)
• --Ogdhekne (talk) 20:54, 23 March 2013 (UTC)
• --Wizzard (talk) 18:44, 27 May 2013 (UTC)

Things to do

• Setup KDE for sandbox
• Commit handling
  • Access
  • Frequency
  • Someone from KDE to do the export??
  • Clarify if such conflicts with coders' changes to PO are possible (docs say nothing and one would assume not)
• Allow login with kde identity? and "KDE contributor" question
• Processing of file moves
• Whitelist allowed languages
• Glossary integration
• Document existing checks and how to add more (cf. pofilter)
• Import existing translation memories?[1] tmx, tbx files? [2] (nothing on their bugtracker[3])
• Group creation (and deletion)
• Consider other aspects of the KDE workflow

KDE teams available for the pilot

• Galician («the translation team would use both a desktop application and a web based application to translate KDE», i.e. a way is needed to mass-edit PO files with pology and then commit them, as with SVN)
• Finnish

Details (draft)

The proposal for an Akademy presentation was submitted and rejected; Nike will not be able to attend Akademy. The project needs a lead willing to push it and to find/assist pioneering language teams.

A web-based translation platform for KDE

Abstract

KDE should consider using web-based translation platforms. I have a proposal. Translatewiki.net would like to support translation of the KDE software interfaces. We are looking for a handful of language teams volunteering to try it out. Translatewiki.net is an online translation platform developed with the translator in mind. It has a community of thousands of translators, some of whom could also translate KDE.

In this talk I will give a short tour over our feature set. I will describe how the translations done in translatewiki.net will integrate with existing KDE processes. At Akademy there are people who have developed and used translatewiki.net, participated in KDE Finnish translation sprints organized using the same tools, or translated in UserBase. There will also be a BoF/workshop session where we can discuss this proposal and try translatewiki.net in action.

Description

In the last Akademy I gave a presentation about translations in the KDE UserBase wiki. Since then the translation interface has been redesigned and we have added new features including advanced search.

Translatewiki.net is used by projects like MediaWiki, OpenStreetMap, EOL and iHRIS. It would benefit us mutually to integrate these translation communities and to also get brand new translators. I want to start with a handful of pilot languages that are volunteering to try it out. I believe that there are enough translators visiting Akademy that I get enough interest to be able to execute this proposal. I have organized a couple of KDE translation sprints with Translate extension (the extensions used both at translatewiki.net and UserBase) with promising results. Before Akademy I will prepare KDE for translation at translatewiki.net and work on integration issues. Actual translation can only happen when there are interested language teams.

I've started translating long ago. I've seen the various file formats, emailing files around, digging version control history to find changes, read the source code to understand the context, proofread translations on a mailing list and waited months for my translations to end up in the product because of busy translation managers. This is not how I want to do translation. Translatewiki.net tries to cut all these blockers and unrelated time wasting activities to let translators produce as many high quality translations as possible.

Bio

Niklas Laxström is a software and language engineer, with an M.A. in Language Technology. He has been a free software contributor since about 2003. Niklas joined Wikipedia in 2004 and soon became a MediaWiki translator. To aid his translation work, he created a wiki which has grown to become translatewiki.net. In 2011 he started working for Wikimedia Foundation as a member of the Language Engineering team, where he has helped to implement the new Translation UX and the Universal Language Selector with its jquery.i18n library to overcome gaps in language support in multilingual websites and operating systems.

Syncing translations between translatewiki.net and KDE SVN (scratchpad)

The following process was used during the two Finnish translation sprints: Preparations for using Translate:

1. Start using PO Summit so that there is no need to handle different translation branches: http://techbase.kde.org/Localization/Workflows/PO_Summit
2. Checkout the POT and PO files in the Translate instance
3. Do the first message import after all needed configuration of Translate and other needed stuff has been done

First step was done by the coordinator of the Finnish translation team. Other steps were done by the Translate instance maintainer. After that periodical syncing of translations:

1. Export the translation from Translate, getting the final PO files
2. Copy the PO files to the coordinator's SVN checkout.
3. Run the script /trunk/l10n-support/scripts/process_orphans.sh from KDE SVN on the coordinator's checkout. (The script is run because the PO files might have been moved, copied or deleted in the SVN since the last import. The script runs those move, copy, delete operations again according to a rule file called process_orphans.txt. It also has operations called merge and mergekeep in its ruleset.)
4. Commit the PO files
5. Run summit merge (one of PO Summit's commands) to merge the updated POT files to PO files
6. Commit the merged PO files
7. Run svn update on the POT and PO files in the Translate instance
8. Import the messages in Translate

Steps 1, 7 and 8 were done by the Translate instance maintainer. Other steps were done by the coordinator. summit scatter can be done whenever. For example always after summit merge. Problems in the above process:

1. Changes made in Translate during the sync (after the export and before the import; after step 1 and before step 8) are probably lost because we want to prefer the translations in SVN. This can be fixed though by allowing the coordinator (or someone else who is able to make the correct decisions) to choose whether to keep the SVN version, the version in Translate or neither and edit the message.
2. Changes made to SVN that are not made after the export (after step 4) and before the import (before step 7) are lost.

Open questions:

• Is it possible for the integration with translatewiki.net to work nicely if one doesn't use PO Summit i.e. has different stable and trunk translation branches? If it is possible, how does it work?
• Conflict resolving during sync and how to not lose translation changes in any case. See problems.

Possible another way of doing the periodical syncing:

1. The coordinator runs summit merge on his/her SVN checkout
2. svn update of the POT and PO files in the Translate instance
3. Import of the messages in Translate

summit scatter can be done whenever. Export can also be done whenever, but care should be taken to only export when all the changes in SVN have been imported to Translate (i.e. Translate is up-to-date). Otherwise the changes will be lost. Problems in this other way:

1. When the names of the message groups change or messages move from one message group to another, translations that are in Translate but not in SVN will probably be lost upon import.
2. Same as the problem number 1 in the process that was used during the Finnish translation sprints.

Problem 1 can be almost fixed by first doing an export, then running process_orphans.sh on the coordinator's checkout and then doing an import. Then only the changes to moved messages that were made after the export and before the import will be lost. Fix for problem 2 is explained above.

Very crude* idea of how to handle conflicts using Lokalize

(*) because implementing it hasn't yet been thought out

1. Export from translatewiki.net
2. Someone merges the translations to SVN by comparing the translations currently in SVN and the exported ones from translatewiki.net. Has to be optimized so that only conflicting ones have to be gone through using Lokalize's merge features. Only differing messages where the last edit time in translatewiki.net is older than or equal to the last edit time of the message in SVN have to be gone through. If finding out the specific SVN commits for each message is hard/slow (probably), the last edit time in SVN can be simplified to be the time of last SVN commit under l10n-support/[language] for all messages. Then remains the problem of comparing that to the edit time in translatewiki.net
3. Commit the changes into SVN and probably run summit merge
4. Import from SVN to translatewiki.net. For differing messages use the SVN versions for messages where the last edit time of the message in translatewiki.net is older than or equal to the last export time; otherwise use the translatewiki.net version (the conflicts will be handled after the next export when merging the changes from translatewiki.net into SVN)

Checking the quality of translations in translatewiki.net would be done using its proofreading function. Problems:

• How to compare timestamps in step 2
• How to use Lokalize to go through only those differing messages where the result of timestamp comparison is the one mentioned in step 2
• Doubt: can one effectively go through changes in many files in Lokalize? Many meaning at least many tens of files, perhaps hundreds.
• Quite reliant on timestamps
• Needs additional support from Lokalize and probably from translatewiki.net. For Lokalize this could be possible to do with its scripting support; I can investigate that.