-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create Diplomat translation submission interface #65
Comments
It seems to me that you are missing the part of the picture where a string that were already translated is updated in As a former leader of the Debian French translation team, I would advise you to use existing tools to tackle this issue. There is many solutions to edit po files out there, and they perfectly handle these issues (and some others). Of course, the difficulty is then to bridge the po file format and the format you are currently using to actually use the translation strings. You may want to use po4a here (but my advice is biaised, I wrote this tool myself 10 years ago). The idea would be that you produce a en.coffee file containing all the strings in english (I'm sure you already have it), and then you use po4a to extract these strings into pot file, and to produce up to date XX.coffee files with the translations from the XX.po files edited by translators. You need to write a new driver for po4a that can deal with coffee files, but I can help if you go this way. Then, all problems of language update and everything is externalized. If you want to present a little interface to translate the po files online, that's very possible. Many similar tools exist, some free (pootle), some not (crowdin or transiflex). That's just a suggestion here. |
I noticed that diplomats sometimes make translations errors. They translate the words correctly but in the wrong context. So when this editor gets developed it's important that they instantly see their translations they are currently working on. They should see it as a preview how it would look on the real page(s). This way they see the complete sentence and they won't make context-related translation mistakes anymore. |
I have some limited experience with translations management, and I agree with @mquinson. Using pot files and established translations workflow is very advisable. We use launchpad translations for unity tweak tool, and I am very much satisfied with it. There is also a pool of Launchpad Translators whose team can be set as the review team, and they ensure good quality of our translations where no team member speaks the target language. Since codecombat already has some translation workflow in place, the only missing link is a helper script to generate pot file with all translatable strings, and to convert the translated po files back to |
I talked with @nwinter about this and we decided that building out our existing system seems better than trying to work in pot and po files into the database objects. With the new patch system, we're already most of the way there, and we want translations to be integrated into the site where we can keep track of them and tie them in with a reward system, rather than external. The pot and po files also wouldn't be able to handle non-text translations (like audio files, or JSON objects) as well as what we've already got. We think the JSON/Treema system of having the translations integrated with the data will end up being the best way forward. Given where we are four months after creating this issue and the patch system has been built recently, there are only a few things left to do to make editing database entities complete, and match or surpass a pot/po system:
These are basically all JSON-walking tasks and some simple interface building. This should handle the case when base text changes, and keep things integrated with the site, and with the patch system it shouldn't be hard for editors to come in and make improvements to existing translations, as @GlenDC mentioned would be useful. Regarding seeing these translations in context, that'll be a little harder, since you would need to play through the level entirely and hit all scripts in order to see all dialogue boxes in context (along with anything else translated), but having the translation system integrated with the editor would help by having it be possible to test the translations in context, whereas an external editor would not. If this system works well, we may consider something similar for the site in general, where we have an interface object which can be edited by diplomats, and store the site strings in the database, rather than having them as files which everyone must load as part of app.js. What do you guys think, @mquinson , @GlenDC , @phanimahesh ? |
The idea will definitely work, but I am very much biased towards the pot/po based translation system, partly because it works well and partly because it is time-tested. But since you say this new system is mostly ready, and it also supports non-text translations, it sounds good. It would indeed be difficult to tie in the translations with a reward system if an external tool is used. These are two major use cases where the new system wins. I did not quite understand what JSON objects need to be "translated". You mentioned them alongside audio files in non-text objects that need translations. Can you elaborate? |
I agree with @sderickson and @nwinter on this one. Our system looks promising, and with enough effort this can really be something great. It will be really great when diplomats can just translate via our website on the fly. We already have many great translators that take time and effort do work their way through git and github. However, I'm sure that we'll reach many more translators, once they can just do their job via an editor on our website. It will also be a great test case for the patch system. |
I agree with @phanimahesh. You will certainly manage to get a great system working. I would have prefered a standard system where you improve the standard tools on need, but I understand that a fully integrated solution is also very promising. At the end of the day, I'd love if codecombat would be perfectly translated to French so that my kids can play with it. My personal feelings about the implementation is not very important. Thanks a lot for this work! |
@phanimahesh Basically in any case where the object in the JSON has two or more properties that are related that can be different between languages. The one example I can think of that happens now is an object that has the text and the audio file of a piece of dialogue. There may be other use cases in the future. For example, I can imagine a case where a JSON object represents a link, and both the text and the url need to be translated, such as to a wikipedia article for a topic. These are cases where the object as a whole should be translated, rather than each piece separately. Thanks for your input guys! |
Sounds good. Good luck for the planned changes ahead. :) |
Thanks to some heroic hacking by @sderickson, It's ready! We are going to send out a big Diplomat email soon. Try it out now and let us hear your feedback and bugs: http://codecombat.com/i18n @Imperadeiro98 @enricpc @Titounkle @kerradus @wakeup @AbnerZheng @Hamtara @gabrielcesar – would love for y'all to take it for a spin. |
It sounds awesome! Thank you @sderickson!!! |
Very good! Nice work. ;) On Wed, Oct 29, 2014 at 6:59 PM, Imperadeiro98 notifications@github.com
Atenciosamente, Gabriel Cesar |
I´ll also take a look as soon as i have time!!But at first sight looks Cheers 2014-10-30 8:32 GMT+01:00 Gabriel Cesar notifications@github.com:
|
I've now tried it out, and it is super!!! Way better than walking throw the level stuff! |
It's very good and easier to use nice work @sderickson ! |
Thanks, everyone! |
I think I found a bug in the translation interface because when i select a language from the combobox and if then I click on word to translate I need reselect the language |
If I do a translation with this tool, when/how does it go live? I'm trying to help with swedish translations. |
It goes live immediately, unless you translated something that doesn't show the translation yet (like the ThangType names only show up i18n in the new inventory and store views, which are basically done but not yet deployed). The stuff in the levels should show up right away, unless it thought it needed to submit a patch (like for a change to an existing translation) instead of just saving the change (for adding new translations). Are there some translations you think should be showing up that aren't yet? |
Yeah, it seems to work like you describe. I managed to translate first dungeon Dungeons of Kithgard. So now I can go ahead and translate the rest. One more thing. How can I change translations of things I already translated that doesn't feel right in context? Thanks! |
Found now that previous translations end up in the bottom of the list. |
Translations for levels are ingrained in the Level documents themselves. We need a way for Diplomats (that is, anyone who wants to) to work on these translations. So the goals for this issue are:
Here's one possible solution:
For each editor (Level, Thang, Article)
Other possible solutions involve:
The text was updated successfully, but these errors were encountered: