The current Drupal process of translating with Gettext PO files, trying to get them into CVS before a release file is generated and then going over hops to update it properly is far from ideal. There are lots of drawbacks, and I started working on a web interface this summer, sponsored by the Google Summer of Code program to improve this situation. Unfortunately the server is not yet ready for prime time (on drupal.org), but there are a number of beta testing servers where some translation teams already try to leverage the cool things this tool offers, so I have lots of feedback on the issue queue.
In the last two weeks, I spent a sizable amount of my free time on improving the navigation user interface, and adding team features to the localization server, which resulted in a huge changeset, and consequently an 5.x-1.0-alpha2 release of the module, which is now available for download.
I put in a lot of thought into designing an interface which is both easier on the newcomers and on the experienced translators, but honestly I focused more on the experienced translators with as easy access to their work as possible, implementing "quick jump forms", direct linking possibility to the translation filter pages, and so on. Note that I am not a professional interface designer, I make plans up as I go along, based on user feedback and my own focus areas.
While there is still lot of room for improvement, I believe this user interface update makes using the application easier. I tried to concentrate on emphasizing the application aspects, but honestly this is not easy when you don't have control over the theme your application is displayed with. I played with adding a web application theme into the mix and requiring that for Localization Server onwards, but then decided that this can be done later if desired. For now the navigation changes can live well with any theme not exactly focused on web applications, but web sites. I see however that in the not so distant future, I might need to tie the interface to a theme, because that allows proper focus on a usable application interface.
Check out some screenshots of how the current interface looks on my Flickr account. Next up is fixing some remaining bugs, as well as new bugs introduced with this navigation interface update and finally improving on the translation interface itself.
Translating what we care about
For World Social Forum 2008 - http://wsf2008.net/ - we have tried to cut down on the number of 11,000 strings or so that we ask volunteer translators to translate into a dozen languages.
In short, we have tried to remove the administrative strings, which we don't care if they are English only.
I created a module to aid this by taking an import of 'unwanted' strings and allowing exports of languages without these strings. This is kept track of simply with a table of lid numbers, so I can see several ways to expose this to a user interface to make it easier for administrators to keep checking off "no, I don't care about that string either." (The first cut in this case was done by going through the whole file and cutting and pasting out what was not going to be seen by regular site participants, and importing that file into what we're calling the 'locale_subset' module. Further strings can be added by this method, but as I get to the point of looking at more sophisticated user interfaces for this functionality to let translators ignore strings, I need ask how this might fit into the tools you keep expanding and improving.)
Should I commit this as a new module, or is there already overlap with the work you are doing, or do you think I should try submitting it as patches to one of the localization-related modules anyway?
Thank you!
hm
We need to think about where will this fit. I know that in several use cases, not translating the admin interface become a goal, but it is also not so easy because of string overlaps between user facing pages and admin pages. If you display an admin page in a certain language, it might be half translated, so you need to ensure that the admin page is displayed in English all around.
Also, for Drupal translations themselfs, the goal is to have Drupal fully localized for "foreign" languages (like mine :), so there is less of a focus on such a tool.
Anyway, it would be great to identify where such a tool would fit. Please send me the module code as a first step, so we can talk about it more, and review the approach taken. Thanks!
e-mailed!
Files also available belowe the module notes on AgaricDesign.com.
Great work! This UI is very
Great work! This UI is very beautiful, thanks!