- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
First website translation - would loved some experienced insight.
Hi all -
As stated, I'm preparing to translate my first website and will be outsourcing the effort. I understand where translations live, how to update them, etc.. But I have a few questions.
- How do I ensure all translations are covered? Simply translate and peruse the website for non-translated terms?
- The translation company has requested that I provide a translation CSV. Should I go this route? I think the answer is yes as opposed to requesting that the company crawl the site with inline translations enabled.
- If not going the inline translation route, should my site translations live in a single file? Or should I stick to module-specific translations?
If any would be so kind as to offer me their experience and workflow, I'd greatly benefit from it as I'm sure others would as well.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Re: First website translation - would loved some experienced insight.
My starting point is usually a language package. Most of packages cover base strings, but being either outdated or translated by somebody who has different needs, they almost always require additional work, sometimes more than just a little bit.
I consider base language translations as the name says: base translations which is another word for "core". One doesn't edit core especially if the language package is created by someone else! Because this renders it un-upgradeable. I always make translations to theme translations (app/design/frontend/{package}/{theme}/locale/xx_XX/translate.csv) Magento theme translation have priority over base translation (inline translation have higher priority still, but since data goes to database and because of that it's not versionable).
About using a third party for translations. There's no good place to get list of untranslated string, unless you start from scratch, in which case you can use a copy of app/locale/en_US as a starting point (there're tons of csv files). I'm pretty sure there're extensions that record missing translation string however. Using a third party agent however doesn't remove the biggest issue of all: considerable part of translations are context specific. English language is pretty lax with grammar and terminology which doesn't bode well with other languages; for example word message could mean 6 or 7 different thing in Estonian language.