Its’ been a while since i last posted an update. So now, I need to open-discuss all my exploits for last 2-3 weeks. I owe lot of thanks to my mentor Mikel Maron for helping me out in testing different features, pointing out some important bugs, suggesting new features and how to code/implement them. Now, coming straight to the point, with help of globalize plugin in osm rails-port, we now have translation feeds. I mean now translators can now have rss feeds for their default language (say spanish (es-ES)), both for pending and completed strings. These are the strings generated or rather added in the globalize_translations table while different views are rendered in that locale.
We have the entire list of pending or completed strings for a particular locale (which is actually the language chosen in user settings page) paginated in groups of ten, which is in turn available as updates by rss feeds. We can simply move to “older strings / newer strings” accordingly. For doing these i needed to add translate_controller.rb, corresponding views and also updated the routes.rb as required. The screen-shot of the “l10n home” that we have in osm rails-port now,
Also, each string has a link that opens up the translation interface where we can view the string and add/update the translation for that particular string. For this purpose, I have used a form, where we can type-in the translation for the string in the translators’ locale. When we add/update translation for a string, its’ updated in the database and if everything works fine, we are confirmed by a flash notice “Translation was updated successfully”. The next time we open the corresponding view, we find the string translated. Here’s the screenshot of the translation interface,
There are some languages which are common to multiple countries. So i had to update the views so that locale without any country tag can be added. I mean earlier, Spanish(es-ES) & German(de-DE) etc got to have the country tag. But now languages like Arabic(ar) common to multiple countries can also be added.
Todo: Now this web-based translation is actually meant to be handled by the ajax in-place-editor of click-to-globalize. Because it places the translatable strings in context, as an advantage. But the problems with CtG are partially fixed. More on this at a later post. So we need the in-place editor start working. Although, the existing translation interface will stay on, so that translators can update translation of any string on the go, if needed just by checking the feeds. They don’t have to search for the concerned view! Thoughts??