From the very inception of our project we designed the ability to support alternative languages. Our past experience was that foreign language is always an after thought. A nightmare to create, support and maintain with copious amounts of duplication of effort and duplication of words. We wanted to fix this by design from day one. We tokenise ALL our static literals (a literal is simply a string of text displayed on a page) in our HTML templates and dynamically substitute the localised literal string for the token as the file is served. That's the simple essence of what we do but it's much, much bigger... This simple idea allows us to make a foreign language the native language for a webapp. Why should a Spanish retailer care about English. So how do we maintain these language translations? We can also also user content management of literals using the exact same technique. We've made it so simple it's doable from a mobile phone. It's also live, any changes that you make are instantly reflected to any users that are looking at them without refresh.
We created a webapp called 'Peach Translate' to help us with English and foreign language literal translations. Like all our live webapps it's multiuser and in this case a closed webapp (you need a login to translate). It's very simple. Since we are English speaking we have a core set of token to English literal mappings. Each time we add a new feature to our webapp framework, or update a feature, we potentially create new or alter existing literals. Peach Translate 'owns' our literal translations for HTML template tokens. As we create new functionality we add our new English tokens/literals. We've a simple translated count that shows which languages have un-translated literals. Our worldwide translators login and simply translate online. Peach Translate is smart, it can write the PHP glue coding that does the dynamic translation on the fly and also generate multiple language translation files. It's a one stop shop for ALL our base literals. But we didn't want to stop there...
Our webapp framework is the foundation needed to build world class native code web applications that run in the cloud. We've a layered approach to our code, visuals and literals. From our lowest layer the 'core' which contains our lowest level communication functionality needed to build an app, layered on top is our base which extends the functionality with chat, private social media, messaging, etc. We can then build other more specific web applications on top of the base, like our live retail offering. As you can see here we have zero duplication of coding and layering of literals too. The core and base literals can be overloaded by the higher level webapp translations to imply more meaning. So what's needed in the retail world is far more specialised in wording than a general base translation. So we built an opportunity in 'Peach Translate' to manage this hierarchy of competing literal translations in the same language, it's just the same for foreign languages too. A translation user has no idea that this layering is happening, they simply select the webapp to translate and Peach Translate does the clever stuff.
So we've a set of 'standard' literals that we create that defines our view of a webapp. Let's take our retail webapp as an example here. We've a set of generic retail literals like "Edit Product" BUT as a retailer you are also certainly specialised in 'Product'. Say that you are an Art Gallery, wouldn't you want "Edit Art" rather than our more generic counterpart? This is where our next layer of user defined literals steps into the arena. As an admin user you also have content management rights in the selected webapp language and can override our defaults with your own personalisation of our live retail. It's very simple at this level, simply right click/long hold, edit and save. Job done. Personalised to your particular flavour of retail. We dynamically apply your changes post server template substitution BUT before client render of the page. It's amazingly fast using our smart connections since they have no concept of round trips to the server. It just works like lightning.
Our localisation model is built on native foreign language. We currently don't support a user swapping languages on a webapp. Why? We believe that this works only on simple static websites of the past. Consider our retail webapp, it's not just about pages with wording, there could be thousands of products (which will have been entered in the default webapp language). If we dynamically swapped out the literal language (which is easily possible) the products remain in say English. Let's no forget the complexities also of user's interactions via newsfeeds, blogs, comments, etc. Wit native foreign language a webapp starts life with the countries native language, products are entered natively and interactions are native language. A Spanish webapp is targetting Spanish speaking clients. This is the model of Amazon, eBay, etc. It's very easy for us to create language specific instances, in a single click, however they are distinct webapps per language with their own stock and product range.
We've put a lot of effort into the marriage of our CMS (Content Management System) and native foreign language. We currently support ALL left to right languages via our unicode implementation. We will handle the right to left languages (like arabic) into the future. If you want to know more or a demo just ask or comment below.