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. [Done]
 * Exchanged security-aspect-related correspondence [Done]
 * Create test message group in correct format [Done]
 * Get Translate to work on an already established message group, loading properties from wiki pages [Done]
 * Get Translate to work on an already established message group, saving properties back to wiki pages [Done]
 * Implement static thumbnail for Special:Translate [Done]
 * Suppress documentation for SVG images [Done]
 * Implement static thumbnail for individual translation page [Done]
 * Steal file description from file description page [Done]
 * Create message files in .i18n.php [Done]
 * Look into customising various messages around Special:Translate [Done]
 * Implement HTML5 regex validation for browsers that support it [Done]
 * Resolve bug when translating same string twice in a row [Done]
 * Tidy up loose ends ahead of end of May deadline for phase 1 [Done]
 * Seek and resolve code review for phase 1 [In progress]
 * Find a way of using Translate's export feature to run custom export code [Done]
 * Write custom code to export back to SVG via re-upload, no error-handling [Doing]
 * Use same code to generate live thumbnails [Target]
 * Code changes to file description pages (with real links). [Future]

Future roadmap

 * 30 June to 7 July: Build export to file functionality ("Phase 2").
 * 7 July to 14 July: Work out best way to prompt dynamic class loading. Ensure that the extension can load most of the full plethora of SVG structures ("Phase 3"), default language selector, iterative fixes to interface.
 * 14 July to 21 July: Ensure correct permissions and error handling in all places; work out how to respond to underlying image changes using hook if necessary.
 * 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