Linport: Design Requirements, Principles, and Assumptions

Last updated: November 28, 2011

This page outlines the design requirements, principles, and assumptions of Linport. The contents of this page are subject to revision and discussion.

Requirements

The following are proposed requirements for the output of the Linport project:

Technical

Self-contained translation project information. The package must contain or point to all information needed to carry out tasks within translation projects.
Feasibility of implementation. It must be possible to develop import/export routines for existing translation tools without requiring substantial modification to their basic design.
Platform/translation tool independence. Linport must not be tied to any specific platform, translation tool, or programming language.
Structured Translation Specifications. Linport must include a way to convey specifications compatible with the forthcoming ISO TS 11669 (see www.ttt.org/specs/).
Support for remote and local access to resources. Resources referenced in a Linport instance may be local (e.g. on a hard drive) or remote (say on a server, accessed via Web services) and both modes of access must be supported.
Open interface. An abstract application software interface description, and several programming-language-specific APIs (all derived from the abstract interface description) and a library for each API, so that applications can use the library rather than accessing a Linport package directly.
Reference implementation. It is insufficient to define just a format or interface. A reference open-source implementation of Linport must be provided.
Package modularization (splitting and joining). Packages must support joining and splitting operations, as needed to support workflow requirements. E.g., a complex multilingual package might be split into multiple bilingual packages, which could then be modified (e.g., through adding a target text) and recombined later on.
Profiles. Linport must allow for profiles, subsets of the overall Linport architecture that support the needs of specific audiences or purposes.

Collaborative

Integration with TIPP. The proposed solution must be compatible with TIPP from Interoperability Now!. We do not believe that developers will implement two solutions to accomplish essentially the same task.

Principles

These principles guide the development of the Linport format. The Linport Project will:

Encourage translation/localization tool vendors and content owners/producers to be early implementers and provide feedback.
Strive for simplicity (so the format is easy for tool vendors and content owners to implement).
The scope of the Linport project does not include the development of payload formats, but it may involve specifying preapproved standard payload formats in strict versions of Linport. The Linport development process, however, does include cooperation with groups that are developing payload formats (e.g., XLIFF).
The Linport format should be based in part on existing tool- or organization-specific package formats.
The initial focus will be on profiles for translation/localization, but allow for profiles to support content management systems and authoring processes in the future.

Assumptions

The following assumptions inform the work of the Linport project:

The format should be standardized in three phases: (a) a “blueprint” for early implementers; (b) an industry standard within OASIS and/or ETSI, and (c) an ISO TC 37 standard.
The documents describing the Linport format should be available as a free download with a Creative Commons Attribution 3.0 license. Any reference implementation software should freely available, including source code, royalty free, and with multiple open source licenses to choose from.
Competition among package formats from multiple projects should be avoided.

Discussion about the contents of this page can be carried out on the Linport mailing list (archives available here).