EPA-Translation as Community-Driven Localisation for Web Apps

Just redefined description for epa-translation:

the community driven translations of web application will extend the application audience beyond the initially targeted countries and lingual dialects.

Why I have started a new project? Ideas are cheap, "every day a dozen" appear and are back logged forever. But this time it became another project to worry about. Worthy of the effort, ApiFusion.com and EPA-WG are actively in progress. 

First, a bit of history. When a new more or less valuable idea appears, it is usually written out and sometimes shared with friends who could have potential interest. Usually that is where its life ends. But this time, Hogne Titlestad from FriendUp invited me to discuss it in their IM group. Apparently the work on translation is in progress there. 

To make it visual for discussion, I thought 3 hours would be sufficient for proof of concept. That is when the project started. And as usual the appetite came during the meal, making me feed-frenzy towards the unusual challenges.

The challenge factor is crucial for hobby style projects. Otherwise, why bother, right?  However, it is not just the challenge swung me to work on proj. The EPA-WG needs a few clear microapplication samples, better in web 3.0 context( cross- service vendors UI and integration ). So far epa-translation seems to be complex enough in functionality and simple enough to understand. 

There is final reason to get it done: epa-translation fits into concept of community-driven content and knowledge/culture evolution which drives modern civilization to progress, where only collective intelligence could counter-balance AI. ( I do recognize other options such as AI and human fusion, but that is a bit in the future. Rather, community initiatives are acting now.)

epa-translation is a part of EPA-WG (Embeddable Progressive Application Working Group) initiative. #OpenSource hosted on GitHub.

---

PS. This project's challenges came from various sides:

* how to make the translation process seamless?

* how to embed microapplication into host app context?

* How to split several flows ( view, edit, sync to cloud) into independent microapplications?

* What radically new pattern microapplication gives and does it give significant advantages?

Some in HTML5 

* How to identify the text chunks in page, select and substitute?

* What local storage to use - localStorage vs IndexedDB? There is large matrix of pros and cons on each side.

Cloud layer

* Should it be server-less based?

* Should the platform be open?

* Could distributed DB be used? BlockChain vs CDN.

I am pretty sure the list of challenges will grow.

JSON added to XmlView, a bookmarklet for web service presentation as sortable table

In addition to early promoted XML in XmlView the JSON format support appeared to be an easy effort. The recognition of JSON format and conversion to XML was all needed to make a sortable table presentation for JSON based web services.

It is not as efficient and scalable as XML though. JSON doubles the browser memory consumption, half of which reside in the JS VM; additional parser for JSON consumes extra CPU/time.

Is it possible to make a faster and smaller memory consumption implementation using JSON without XML?

I guess not. XML reside in browser memory and is not a subject for JS limitations which will be in place for JSON. There is no multi-threaded(yet?) template transformation from JSON to HTML. Not to mention there is no way to render directly DOM by template engine besides XSLT.

Potential for the improvement

There is a prototype for virtual scrolling via XSLT. It could be used as a base for rendering just visible part of data delegation the rendering on scroll in real time.

Happy coding!

JS UI Widget design

the work in progress, content will evolve over time.

Requirements

HTML,CSS and other resources to represent insulated independently designed and developed module.
While those component types are not mandatory, using standard components increases manageability, productivity and reliability. From managing point having the component in publicly-accepted standard allows to easier find worker, reassign the job, pick the best expert for critical peace, match the standard and utilize this standard-based tools including validation, tests, compilation and transformations, other tiers(component types) interfacing protocol  and so on.

The resource types listed individually in order of development life cycle:

Requirements and overview documents. Alternatives are online docs and static file format. Online is more about collaboration, static is the currently accepted snapshot. Static content ideally to refer online threaded discussion with ability to back-refer location inside of static content. As static content for now HTML is universal. It is popular, has ability to include raster and vector graphics, print-friendly.

Prototypes and mockup. Adobe (Photoshop & Illustrator), Visio are most industry-accepted tools. All have ability to keep the project in cross-platform and -media format. SVG is the best candidate. Another approach is to have public format(SVG, PNG, PDF) be a secondary, synchronized on each modification of original. I personally like 3D MAX for those purposes, but as project manager will not use it unless have at least few people on team familiar with concept and product.

HTML based templates.All UI developers are familiar with this format. Any custom one is narrowing the number of people familiar with it and as result cut managing ability. The balance of given and taken out functionality is always in place. HTML itself does not have all "template" functionality of course. But it is popular to under estimate its power.
I like the ability to fuse different technologies in compatible way. For example dojo toolkit dijit 1.x has given HTML customization via data-dojo-xxx attributes leaving the HTML functionality intact.
While among "native" templates the XSLT is oldest and most robust one, it is not 100% HTML compatible. It is not easy to find people skilled in both XSLT and HTML.

The a lack of development cycle support is applicable to all template versions. XSLT has best coverage on that( preview, debug, rudimentary documentation and test suite).

Another reason of tempate format selection could be the native engine(parser and binding) support. On web client the browser itself is one of such engines.On server side multiple HTML parser available, XML is the simplest one. Native support given performance via native code, multithreaded and asynchronous processing.
IMO for simple widgets DTK 1.x dijit format is best(but with browser loading and parsing instead of JS one). For complex is XSLT.

CSS and style formats. CSS is outdated in terms of complex project requirements. XStyle provides rudimentary but still way more powerful control over complex styling rules. For relatively simple UI the set of rules is limited and as result will (and should) fit into CSS limits. If not, than styles are subject for insulation into own module(style themes and i18N localization are samples of such). Good styling format will be back-compatible with native CSS and give as shim as OOP abstractions. At the moment it does not exist.

Tiers Plumbing. The configurable loader should be sufficient to support distributed compile, server- and client-side modules bindings in case the tier resources will be loadable directly or by loader plugins ( see cssI! as sample ).  AMD or UMD loaders are good fit.

Design

Phases of widget life. 

Placeholder, Facade, UI and runtime. (de-)serialization and View Model. Interaction with data model.
Incremental and steaming rendering. Interruptable and prioritized rendering.

Presentation variations.

I18N,  media device (display|print).

Shims.

Declarative programming as effective way to target rendering options according to destination environment and configuration.
The shim name has dual meaning: "marker" in declarative programming and implementation module for it.