Design, ideas, requirements for the new design

OSGI

Minimally refactor the code to be more OSGI friendly and our modules deployable as OSGI plugins. Experiment with light OSGI containers for use in client tools such as Rainbow.

Central Repository

It would be nice to have the Okapi artifacts hosted in the Central Repository. But, while we should strive to achieve the best guideline for our POMs, Central Repository requirements may be difficult to achive.

IDs

It would be better to enforce IDs to be at least NMTOKEN. (It is an XLIFF 2.0 requirement too).

Project file format

We need a common project-like file format that we can share across tools. In XML, YAML or JSON.

Common pipeline runner

We need a shared library to execute pipelines, from different UI, e.g Tikal or Rainbow, etc.

Inline Content

the inline content model should be updated to allow

• access of all inline codes at the unit level
• management of all inline codes for a given source or target done at the text container level (vs text fragment).
• isolated cases should not be coded but decided on output.
• tag information should include the type of tag (start, end, standalone) as well as the type of object represented (inline code, annotation-only span, protected text placeholder).
• there should be a way to protect content, like a simple collapse/expand function that would hide the content marked as not-translatable.
• Possibly reduce the limitation related to the use of PUA characters for the markers.
• Add flag that will prevent inline code from being "simplified" (moved to skeleton).
• properties of an inline object that are common to the opening and closing tags must be automatically synchronized (i.e. if you set the type from the closing-tag object, the type in the opening-tag object must be updated immediately and automatically).

See newDesign_Inline_Content

Filter Configuration Mapper

See https://groups.google.com/forum/#!topic/okapi-devel/fthA2OvIkdg

Refactor to be more friendly to server applications using streams only. Avoid Class.forName if possible (except for plugins), avoid extra disk reads.

Filter Encoders

See https://groups.google.com/forum/#!topic/okapi-devel/nSxdLuJUY_0

Pipeline

• True pipeline implementation.
• Most of the interface may stay the same.
• Each step would be threaded.
• Possibly Separating pipeline and batch-items
• Pipeline should be able to run all the events on a single step before moving to the next step. This would be possible with a backing store for the event.

Stream Friendly

Should make the framework more stream-friendly. This includes refactoring RawDocument if possible.

Use Doxygen

we could enhance our source code documentation using Doxygen (www.doxygen.org).

See https://groups.google.com/forum/#!topic/okapi-devel/vUcg_SQMRd4

Better documentation in the source code. And high-level explanation in the wiki.

General Error Handler

Universal abstraction components can register to check status/state of the run. Shouldn't mix UI messages with logging.

Mimetype Cleanup

• add missing mimetypes
• standardize mimetypes and extensions
• filter configurations have their own mimetypes

Logging

Need a better logging / feedback. Making logging consistent.

Format Detection

Need some kind of sniffer for the formats. Used also in the filters to detect wrong settings.

Cloning is Evil

section on clone() in Joshua Bloch's "Understanding Java" http://stackoverflow.com/questions/11905630/java-super-clone-method-and-inheritance Better to use copy constructors and factory methods?

FilterWriters should work with Segmented TextUnits

Currently we have special merge code that accounts for segmented formats like ttx, txml, xliff etc.. These are the only formats were segments are merged. But there is no reason to loose this information. If the translated xliff is segmented it should be merged segmented. This will require a change in some of the filter writers to expect segmented content and work with it appropriately.