Considering to translate multiroutemap on Translatewiki
we're considering using Translatewiki for translation of multiroutemap. Translations consist of .po files for interface messages and .rst files for information pages. All source code is as free as possible (main developer Sarah Hoffman dedicates her contributions to Public Domain where possible), and the project has been running for some time now, with French, Norwegian, Italian, German and Spanish translations.
Are you interested in taking us in? What would you require?
Translating:New_project sums pretty much what we want. Usually as long as the project developers are interested and work together us the other requirements can be worked out. We also expect commitment to respond and solve i18n related issues that our translators find.
Would you like to chat with me on IRC or skype?
After the IRC chat last evening I e-mailed with Sarah. It all looks good to her, and she'll take sign up and take a look around this evening. So now we're mostly just waiting for you to do the i18n code review, look into how to handle .rst, and set it up :)
Some review comments:
- Where's the pot file?
- Is "bbox" supposed to be a known term?
- There are a few patchwork messages. It looks like some parts of the patchwork are also not localisable. Can't you use something like wikipedia:Markdown to keep sentences together?
- last update (presumably followed by a date)
- For information about the syntax, see (presumably followed by a link with an unknown link description)
- Contents of this page licensend under (presumably followed by a link with a license as link description)
- Cryptic message: Recognized Values for osmc:symbol
- Some title casing is being used, but I'm uncertain if it's used consistently.
Bbox is short for bounding box, a rectangular area of the map that is shown (I think)
bbox should probably be expanded, and osmc:symbol explained (and expanded). I'll let Sarah respond to the pot file and patchwork messages, but I suppose it has been done to keep links and "dynamic" messages away from translators. You're asking for title casing to be consistent, or are you saying that Title Should Be Like This?
I'm asking for it to be consistent -- I don't know the product, but I think there may be inconsistencies. In MediaWiki "We use it like this", but I don't really have a preference as to "How It's Used in English". Translators have to pick their own preference (in Dutch "It's usually like this").
Comments on the comments:
- There is no pot file in django. To create a new language there is a command:
django-admin makemessages -l <two-letter language code>
. They are updated with
django-admin makemessages -aand finally compiled with
django-admin compilemessages. You need to do this from the directory above the locale directory.
- Putting the links into the patchwork messages is slightly tricky because they are django links that are dynamically created. I'll have a look. I wouldn't consider 'last update' as a patchwork message.
The other stuff should indeed be fixed/clarified.
We'd need a pot file somehow. Otherwise there is nothing to bootstrap from.
I've added an empty template language here: django/locale/xx/LC_MESSAGES/django.po
Would that be sufficient for bootstrapping?
I've made an issue to follow this up. As for the osmc:symbol message, it is appropriate unexpanded/unexplained in it's context, but should be explained on the help pages. I have been unable to find out what it stands for, however.
I believe we have resolved all the issues raised by Siebrand now. Have you looked into supporting .rst-files? I'm going to present use of multiroutemap in Joensuu, Finland on Tuesday, and was hoping it would be working until then, so that I could show how easy it is to translate, and perhaps tempt some of our other project partners to use/contribute to it.
Oh cool I didn't know you are coming to Finland.
The problem with RST is that it's not a i18n file format, but document format like word or wikitext. It seems to be similar to wikitext, so one solution would be to add the text into wikipages and use the page translation feature of Translate to translate them. Though, the syntax is not familiar to our translators and they might make mistakes with that.
In any case we can start with the Gettext files, and start sorting out the details with commit access, creating project description page and things like that. If you can catch me on IRC or Skype we can do that more efficiently.
Ok, we can start with the Gettext files, but if it's not too much hassle, I'd just set up translating of the .rst files through wikipages. We can look through them before they go into production. As for the rest:
- Commit access: I assume Sarah should give Siebrand push access?
- Project description: I've made a draft here. Could you make a "logo" based on your top right icons (or something more "proper" if you like) Sarah? Should have a short description when the long one is done.
- Sarah has changed the name from "multiroutemap" to "waymarked-trails-site" on Github. I think we should call it "Waymarked Trails" and "waymarked-trails" if lower case and sans space is needed.
- New languages are added by adding them on new line around here.
Sarah says rst is not set in stone, Django can also do markdown and textile out of the box. Suggest you create an example what you can produce and then she can have a look on how to integrate it, but the help pages can be implemented afterwards.
I suppose the page translation feature is used on web interface? I think that could be useable for the help pages. We do not have to use RST, markdown is more similar to MediaWiki syntax and for example headings can be formatted exactly the same way. I suppose most effort would go in to importing the existing translations and setting up an export to translated files.
Page translation is not the best option here, I think. It does not have export capabilities and requires too much manual maintenance. You could use page translation if you were to install your own MediaWiki instance with Translate, but if you want the translations in your SCM solution, you need an FFS class (File Format Support).
Sarah has suggested to move the help pages to gettext files for translation here. However, presuming that we managed to get them into a separate template file, could we then also have them in a separate group the way it is done with OpenStreetMap and potlatch? That way UI and help page messages aren't mixed, and translators could easier prioritise the UI.