Extension talk:Translate/Mass migration tools

Feedback
Ok, this looks good enough a draft to seek more comments, especially as you need to write the "use cases" section and that can only be done by hearing from users: so far you only had the point of view of one translation admin, me; I can "represent" most of the concerns from MediaWiki.org, Meta-Wiki and Commons translation admins but not everything. Stakeholders/venues to contact, where you can post an invite to come check your proposal, comment it and watchlist it: --Nemo 12:45, 2 March 2014 (UTC)
 * Project talk:Language policy, Project:Current issues
 * OSM
 * userbase.kde.org and other wikis of the family (whatever place they use to discuss)
 * m:Meta talk:Babylon
 * commons:Commons:Translators' noticeboard
 * wikidata:Wikidata:Translators' noticeboard
 * mediawiki-i18n, extension talk:Translate
 * Other wikis, among the 100+ using Translate, which have a lot of old translations

Feedback plus suggesttions
Having read your proposal, I think it is worth being implemented.

Question: How to implement it?
 * As an extension inside MediaWiki?
 * Somewhat indepentent, such as with the Pywikibot framework?

A workflow question: Importing existing translations (i.e. step 2) likely often needs to be done by people who can read and understand these translations well enough. It may take a long time to find these experts. What happens meanwhile, so as to not hamper translating to other languages? Is it possible to have a consistent mix of unsplit translatons while other language pages and the source page are split already?

Ideas and suggestions: --Purodha Blissenbach (talk) 11:37, 10 March 2014 (UTC)
 * First time splitting a source page into translateable units is language dependant. At least it depends on language types and writing systems. I would suggest to create some very basic code for it, and then only implement English, and thus likely some other Latin script based European languages, to begin with. English would be the most predominant use case anyways.
 * Splitting strategies vary on text types. Thus allow users to choose the best one. At least, I would suggest to have "by sentence", plus "by paragraph", plus, of course, what existing markup may suggest.