This is a post in the series about data as an asset, see previous posts here and here.
Ruby on Rails, ColdFusion, JSP, ASP, ASP.NET et al
All mainstream back-end application environments incorporate an internationalization framework with high level of abstraction both in terms of API calls that dispense with custom solutions as well as data access and structuring. These technologies support many locales out-of-the-box and facilitate the separation of application logic from data via external resources. Ruby uses YAML; ColdFusion, as a Java EE application, and JSP rely on resource bundles; ASP.NET dynamically compiles into resx assemblies.
This is a post in the series about data as an asset, see previous post here.
Asynchronous technologies were devised before the turn of the millennium to address the issue of high traffic and mandatory reloads of dynamic websites. This evolution advanced hand-in-hand with the development of serialized, atomic data-oriented formats and systems that opened the gate for innovative services and laid the groundwork for the so-called Web 2.0. Data-driven architectures gave rise to the back-end/front-end dichotomy, which in turn allowed for a significant leap in complexity, design, modularity, and more recently, the integration of various platforms into a consolidated ecosystem. As a second instalment on internationalized web architectures, this post is still mainly concerned with the practical aspects. Later in the series, we will look into the ongoing transformation of technologies and talk about the change of mainstream attitude from well-defined to hybrid/fuzzy logic.
Think about data as locale-, scope and objective-invariant. The steep evolution of technology has finally allowed it to be managed as a strategic asset that combines every aspect of business – or at least in theory. Our current series of posts will take a look at what localization has to contribute, starting with the practical problem of optimizing web architectures.
We have touched upon interoperability in our terminology lifecycle management posts, but today we arrived at a major milestone with our back-end tool, so it’s time for a second helping. It may seem redundant to develop our own software that converts and manages data, when solutions that are available in every LSP’s toolbox, such as qTerm, MultiTerm or Swordfish handle conversion as well to a certain extent. On the bright side, their interoperability capabilities satisfy straightforward and elementary processes; however, as complexity rises, their limitations become apparent.