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.

Installation and configuration
To install and setup the TranslateSvg extension (warning: the current status of the extension is strictly alpha):
 * Ensure you have a working, fairly up-to-date MediaWiki installation (1.18.1 or above should do it)
 * Enable SVG handling, SVG uploads and file subpages in your LocalSettings.php (Manual:SVG). Getting this right can be tricky. Example code:
 * Test normal SVG rendering works by uploading a test file
 * Install the Translate extension, TranslateSvg branch. To do this, you can either grab it from Git (I'll leave you to figure out how to do that), so get a snapshot:
 * Download Translate-f46f7e6.tar.gz (approximate size 1.5MB)
 * Extract the Translate-f46f7e6 folder to /w/extensions, such that /w/extensions/Translate-f46f7e6 now exists (Windows users may need to download a program like 7-zip to help with this).
 * Rename that folder to something more convenient e.g. /w/extensions/Translate
 * Configure the Translate extension by editing your LocalSettings.php, full options are available at Help:Extension:Translate/Configuration, but the TL;DR version can be summarised as:
 * Install the TranslateSvg extension by downloading a .tar.gz file from Special:ExtensionDistributor/TranslateSvg, and extract it in the same manner, so that /w/extensions/TranslateSvg now exists.
 * (optional) Configure TranslateSvg by adding the following line to your LocalSettings.php (there are some other options but you shouldn't need to change them):
 * (optional) Register that username on your wiki, and probably give them the bot flag.
 * Navigate to an SVG file containing a string, and follow the link to start translation

Status
[preliminary work and phase 1 collapsed into an HTML comment]


 * 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 [Done]
 * Use same code to generate live thumbnails [Done]
 * Seek and resolve code review for phase 1 [In progress]
 * Code changes to file description pages (with real links). [Done]
 * Consider the impact of unsaved changes on correct file description pages [Done]
 * Push 'TranslateBeforeSpecialPage' and 'TranslateNoSuchGroupFound' to Gerrit [Done]
 * Enquire about temp file clearance issues [Doing]
 * Work with Krinkle to sign off basic JS hooks system [Doing]
 * Understand and write translation fuzzy/invalidation code
 * Seek and resolve code review for phase 2
 * Have all hooks and other modifications to Translate signed off, branched merged
 * Add colour picker
 * Consider modifying/removing "suggestions". [Future]

Future roadmap

 * 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