{"issue":{"state":"open","created_at":"2011-10-07T10:32:26Z","updated_at":"2011-11-28T19:50:15Z","user":{"gravatar_id":"6636f5733dd09025d87b33eb14c7b2fc","id":84501,"url":"https://api.github.com/users/espenak","avatar_url":"https://secure.gravatar.com/avatar/6636f5733dd09025d87b33eb14c7b2fc?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","login":"espenak"},"comments":1,"body":"We need to start considering internationalization. The challenge is that most of our interface is written in javascript, however some error messages generated serverside. We should find a good solution for internationalization, and start marking all our user-interface exposed strings for translation. However, maintaining multiple translations with the rate of development devilry is seeing at this point has high probability of leading to bugs in translations and unneeded overhead for developers. But this should not stop us from preparing devilry for internationalization.","assignee":null,"number":223,"id":1842072,"labels":[{"name":"new feature","color":"000dff","url":"https://api.github.com/repos/devilry/devilry-django/labels/new+feature"}],"pull_request":{"patch_url":null,"html_url":null,"diff_url":null},"title":"Internationalization","closed_at":null,"html_url":"https://github.com/devilry/devilry-django/issues/223","url":"https://api.github.com/repos/devilry/devilry-django/issues/223","milestone":null},"action":"created","comment":{"created_at":"2011-11-28T19:50:15Z","updated_at":"2011-11-28T19:50:15Z","user":{"gravatar_id":"6636f5733dd09025d87b33eb14c7b2fc","id":84501,"url":"https://api.github.com/users/espenak","avatar_url":"https://secure.gravatar.com/avatar/6636f5733dd09025d87b33eb14c7b2fc?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","login":"espenak"},"body":"I suggest we use the approach that is common in Java environments instead of the gettext method. We should use a property format that allows us to define translation strings. I propose that we use YAML for this, since it is easy to read and write, and parsers are available for more or less any programming language, including JavaScript and Python.\r\n\r\n## Format proposal\r\n\r\n- Each application provides their translations in ``static/#appname#/i18n/``.\r\n- The default string is placed in ``messages.yaml``.\r\n- Localized versions are in ``messages_#language#.yaml`` (I.E.: ``messages_nb.yaml``).\r\n- We provide a script that merge all of the translations into a single _JSON_ file for each language. I belive JSON is a good choice for this since it is natively supported in ExtJS and Python. This makes _YAML_ only required for developers and translators.\r\n- Server-side, translations are loaded from JSON, and cached, the first time they are required.\r\n- Client-side, translations are loaded from static file storage by the JavaScript library.\r\n\r\n## Making it easy to contribute translations\r\n\r\nWe should create a web-gui where users can:\r\n\r\n- Load JSON translations\r\n- Save JSON translations\r\n- Edit in a user-friendly way. Should be easy with http://docs.sencha.com/ext-js/4-0/#!/api/Ext.grid.property.Grid where the name is the default _english_ translation and the value is the translation.\r\n- Note that for it to be easy to contribute such translations back into Devilry, we should be able to decouple a JSON file and add it to the appropriate YAML files within each app. As long as we do not allow keys in the translations that are not present in the corresponding _messages.yaml_, and no duplicate entries in _messages.yaml_, this is easy.","id":2906198,"url":"https://api.github.com/repos/devilry/devilry-django/issues/comments/2906198"}}