Internationalization submission system

[neocotic]

Create a system that will allow anyone to submit translations of the i18n messages.

To simplify the translation for potential authors, descriptions should be added to messages and examples should be added to placeholders (where appropriate).

Key points;

• Any technology and/or service can be used to achieve this
• Preferably, create a framework that could be used for other extensions
• Will probably need an area for authors (translate and submit), users (review), and developers (review and manage)
• Could possibly implement voting/veto system to allow collaboration

Information to be captured:

• Author name & email address (which should be added to list of contributors and used when updates are required)
  • Both should be validated
• Locale code (selected from a dropdown containing all support languages.
• Version of the extension that the translation is based on
  • Should be validated
• JSON generated for all of the translated messages
  • Invalid messages (i.e. blank) are excluded from results
  • Message descriptions and all placeholders are taken from the source translation and thus should always be in the original language
  • Messages and placeholders are sorted alphabetically

Additionally, another system (or feature of this system) is recommended to diff' translations in order to detect what - if any -messages are missing from a submission and that any placeholders that are omitted are highlighted.

A recommended final step for the process is to roughly translate (e.g. using Google Translate) for quick-scan checks for malicious submissions. If a single malicious is found the whole translation is rejected and the author is then informed.

Finally, the CSS for the options page and desktop notifications will need to be changed to support different text directions. For example;

body {
  direction: __MSG_@@bidi_dir__;
}

[neocotic]

Brainstorming use cases for a possible web flow solution...

Homepage

1. Display Dashboard

Dashboard

The dashboard displays different in the following contexts;

• Authenticated:
  • Extension: Display versions with a link to Version Registration
  • Version: Display version overview (messages etc.) and submissions with a link to Translation
  • Translation: Display expanded version overview, edit fields for each message and reviews
  • None: Display stat widgets for owned and other extensions and translations with a link to Extension Registration
• Unauthenticated:
  • Display stat widgets with a link to User Registration

User Registration

1. Authenticate user
2. Display links to Dashboard and Extension Registration

Extension Registration

1. Authenticate user
2. Request and validate extension ID
3. Check if extension ID exists and that user email matches that on the web store (using logic similar to MyExtensions)
4. Store extension
5. Display Dashboard in extension context

Version Registration

1. Authenticate user (must be owner of extension in context)
2. Display Dashboard in version context
3. Request and validate contents of messages.json for that version
4. Parse contents as JSON and continue validation
5. Store contents along with current timestamp (used for versioning)
6. Display Dashboard in version context

Translation

1. Authenticate user
2. Display Dashboard in translation context
3. Request and validate target locale
4. Request and validate message translations
   • Perform visual progress updates throughout the translation process (e.g progress bars and ticks)
5. Store translation for review

[neocotic]

Another alternative is to check out crowdin as it might already suit my needs. Open source projects are free but I need to complete their moderation form.

[neocotic]

After all that it seems crowdin is the perfect solution! They don't charge open source projects and support Google Chrome Extensions off the shelf.

I'll keep this open as I need to update the FAQ to document this but anyone can now submit a translation using at http://i18n.tmpl.at.

Also, I want to add descriptions and examples to all messages and placeholders respectively as well as add new messages to cover the web store text. API keys and OAuth client ID and secret should be moved back in to the code from the i18n bundles to simplify translations.