Versions 0.2.0 of BingTranslate and GoogleTranslate for Magento
For some time, our BingTranslate and GoogleTranslate extensions made various Magento users happy by allowing them to translate products through their Magento backend. Many times, automated translations are off - making real-time frontend translations less perfect. Our extensions make a difference by allowing backend-based translations to be saved and optimized afterwards. Now version 0.2.0 brings various exciting new features to both extensions.
Update on APIs
GoogleTranslate is a tool known to everybody, but Microsoft offers a similar service: Microsoft Translator, which was previously dubbed Bing Translator. Both services offer automatic translations - for GoogleTranslate the API costs money right from the start, for the Microsoft Translation API the first huge bunch of words is for free. We tend to like the results of BingTranslate a bit more (yes yes, Microsoft). But both solutions are solid.
Still, errors are sometimes there. A complex English text might be translated to a weird abstract poem in French. Therefor, automatic translation in the frontend (real-time) is not perfect. If text is off, there is no way to correct this. With our BingTranslate and GoogleTranslate extensions, the translation process happens in the backend - reacting at your own mouse-clicks - which allows you to (theoretically) correct wrong translations.
Also, real-time translations slow down your Magento shop. Backend translations do not.
Not only products, but also categories, CMS-pages and blocks
A major improvement is the support for categories, CMS-pages and blocks. Our previous versions only offered translating the various product-attributes for a Magento product. The new versions also add-in support for Magento product-categories, CMS-pages and blocks.
Manual override of source and destination language
This change in support also gave us some headaches: With products, we could rely on the source-language and destination-language as it was determined by the Magento scope of that page (Global, Website, Store View). But with CMS-pages, categories and static blocks, there is no such scope. Yes, you can determine for which scope the category or CMS-page should be used, but these are multiple selects - and they don't point to one destination language exclusively.
The solution required a rework of all code, but was in the end pretty straight-forward: Instead of only relying on the detected languages, the new extensions offer a simple toolbar in the bottom of all pages: There you can override the detected languages at choice: If the current product-scope belongs to an Italian locale, but actually the text you are dealing with should be translated from German to English, you can! The right languages can be simply selected in the bottom, and there you go.
With the rewrite of the extensions, we also introduced a cool new feature: Instead of only working from within the backend, we abstracted a Model-class Translator which can also be used for scripted translations. This sounds very cool, but - as the current APIs of GoogleTranslate and BingTranslate are not free anymore - this could lead to larger costs quickly. Be careful when writing a script that translates all your 20.000 products through cron!