Extension:TranslateSvg/2.0

This is the planning page for version 2.0 of the TranslateSvg extension, a project being undertaken by Harry Burt (User:Jarry1250) as part of Google Summer of Code 2012.

Status

 * List of SVGs to be analysed compiled [Done]
 * Reach out to translators [Done]
 * Translate downloaded from Git, then installed and configured on local test wiki [Done]
 * 10,000 SVGs downloaded ready to be analysed [Done]
 * Investigations into Translate’s terminology and how TranslateSvg will fit with that [Done]
 * This page created, including preliminary workflow [Done]
 * 10,000 SVGs analysed [Done]
 * Initial designs generated [Done]
 * Feedback sought on designs [Done]
 * Get to grips with how parameters other than string could be saved within the Translate infrastructure. [Target]

Future roadmap

 * Now until to 17 May: Fixing priorities, methods and designs (for the main translation page and the additions to the file description page). This would include interviews with translators – in order to understand their needs fully. Agree performance-friendly methods with mentor and other developers.
 * 17 May to 1 June: Get Translate to work on an already established message group, round-tripping properly.
 * 1 June to 3 June: Discussions about the project at the Berlin Hackathon.
 * 2 June to 9 June: Code changes to file description pages (with dummy links).
 * 9 June to 23 June: Temporary lull.
 * 23 June to 30 June: Finish proposed new interface, open up for testing and comments, make adjustments
 * 30 June to 14 July: Do most of work with regard to the extension handling the full plethora of SVG structures, iterative fixes to interface.
 * 14 July to 21 July: Finish work on handling SVG files, including permissions and error handling.
 * 21 July to 11 August: Heavy-duty code review, documentation, and several rounds of testing with real-world translators.
 * 11 August to 20 August: Final polish, integration focussed elements. Pencils down on official project.
 * 20 August to end of October (provisional): Prepare for deployment if required

Suggested workflow

 * User wants to use diagram or other SVG image, but it is not available in her or her language.
 * User clicks link to special page in order to translate it
 * If not already present, a message group is created, filled with defaults, and saved
 * The Translate interface is loaded and displayed to the user.
 * User selects the desired language(s) and translates using Translate interface. After each, the translation is saved back in the usual Translate wiki way.
 * When user is finished with change(s), user can either (a) wait until midnight or (b) press a big save button. After either has been done, the export process reassembles the message files back into the SVG in the form of an "Upload a new version of this file"-style update (checking for edit conflicts and fixing as appropriate!).
 * The user is able to insert the SVG thumb, now translated into the new language, into any MediaWiki document using the lang=xx attribute.

Required deliverables
The final extension should:
 * be able to handle the translation 99%+ of text embedded in SVGs, taking account of (for example) meaningful s, italics, bold, superscript, subscript and other formatting using well-documented methods;
 * provide a functioning, internationalisable and polished interface able to adjust for translations (with a "native" feel and a minimum of visual clutter):
 * in different writing scripts,
 * with different x/y positioning,
 * and in right-to-left (RTL) languages;
 * modify file description pages, to enable visitors to view files in different languages and provide them with easy access to the translation mechanism;
 * be written to cope with "evolving" SVG files, i.e. those which go through a repeated translation-modification cycle;
 * be well documented, or, even better, be sufficiently simple that it needs little in the way of official documentation;
 * implement logical and informative permissions and error-handling;
 * and do all of the above in a resource-efficient manner, even for large SVGs; or, if this proves impossible, at least implement a reasonable upper limit with regard to performance (similar to the long-time situation with large PNG files).

If time permits
The final extension could:
 * provide quality control via a special logging action (reverting being handled natively via MediaWiki);
 * separate a new SVG-translation user right from the usual upload user right to allow for more granular permissions;
 * ensure SVG-file-parsing system is sufficiently logical and/or modular to be easily extensible by future developers.

Further details

 * Results of SVG analysis