###Background:
Our nonprofit organization is about to begin using Discourse as part of our multi-lingual membership community. Our site and related applications currently support 10 languages, and we like to have new functions mostly translated before rolling them out to our users.
###My Problem:
Looking at the currently supported languages, and the great work being done in Transifex, I’m seeing a need for some serious work in a few of the languages we’d like to support.
These are the languages that are currently incomplete that we need to have translated before we launch:
Myanmar (Burmese)
Thai
Khmer
Indonesian
Swahili (Kiswahili)
###A Solution?
I might be able to find some money to invest in translating the consumer views into a few additional languages, but probably couldn’t justify paying for the administrative views. (Grants would cover one but not the other.)
Before I move forward I want to be sure that I’m not duplicating someone else’s work, and that I’m not wasting money.
What do I need to know before I hire some of our translators to do the work?
Are there any gotchas I need to be aware of before I start sending the YAML files out?
I’m looking for some people with experience translating Discourse to weigh in
All of the work would be put into Transifex, but probably by me. It’s hard enough finding Burmese translators that work in unicode, let alone ones that would want to learn a whole new system just to work for us. I’d be sending out the Yaml files and then uploading them into Transifex. I would also provide them with the glossary.
Don’t do that! Transifex is quite easy to use. Translating just the YAML files will lead to a lot of problems and additional work for you. Transifex takes care of all the hard stuff for you: pluralization, updating the translations when the English source files change, collaboration with other translators and Unicode won’t be a problem either
@gerhard Sounds like I won’t be using our usual translators for this then, we usually hire from our regional offices and get the translations back in all kinds of formats… which I then have to massage into whatever the destination format will be.
The problem with unicode wasn’t really with unicode itself, but finding translators that know how to do Burmese in Unicode, most of them work in Zawgyi (a custom font and keyboard system) that predates the scripts inclusion in UTF.
Any recommendation as to where to hire translators that might already understand Transifex or similar systems?
@codinghorror That’s a VERY helpful article. One thing I noticed in there was to start with the client.{lang}.yml file as that contains the “user-facing labels.” I took a look through the server.en.yml file and found a lot of strings that looked like they would be sent to users as well:
####Example:
Sorry, new users can only put %{count} links in a post.
Will I be missing a lot if we only translate the client file?
Clearly I have to keep costs down here, but if I’m going to ask for money, I need to know if the job will seem done when we put in the translations.
THANKS again everyone for helping. Keep the suggestions coming!
@Falco Oh, that makes a lot of sense and is fundamentally different than my understanding. Makes sense that the one being sent wholesale to the user through javascript would be smaller. I was thinking they referred to user space and admin space, but clearly the naming doesn’t mean that now that I understand your post.
The client.en.yml contains an “admin_js” section. Everything belonging to it will only show up in the admin interface. So, you could ignore those if you want.
