Skip to content

Goals and non-goals #77

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Jun 1, 2020
Merged

Goals and non-goals #77

Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
3be7b11
Document goals and non-goals
stasm Apr 16, 2020
544ffad
Goals and deliverables, rev2
stasm May 14, 2020
e332116
Remove _complex_, remove reference to CLDR
stasm May 15, 2020
8979970
Replace translations with localizable message strings
stasm May 15, 2020
725cc21
Make goal no. 5 broader wrt. TMS and CAT
stasm May 18, 2020
a3ed25a
Make goal no. 6 more explicit: implementations, frameworks, tools
stasm May 18, 2020
311b0a7
Feedback from the May 18 meeting:
stasm May 20, 2020
352a98b
Update goal-5: Be capable of...
stasm May 28, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
69 changes: 69 additions & 0 deletions guidelines/goals.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
# Goals and Non-Goals

This document defines the purpose of the Message Format Working Group (MFWG)
and informs the decisions about the scope and the priorities of its efforts.

## Goals

The primary task of the MFWG is to develop an industry standard for the
representation of localizable message strings. The design goals are listed
below.

1. Express grammatical features, such as plurals, genders, and inflections.

2. Express other variance in translation, due to linguistic and regional
features, the presentation media, context, circumstance, and other factors.

3. Express formattable data, such as numbers, dates, currencies, and units.

4. Represent structured data alongside translations, such as markup, comments,
and metadata.

5. Be capable of localization roundtrip.

6. Enable the creation of implementations, frameworks and tools building on
top of the standard, manifesting different ideas and programming paradigms,
and optimized for different uses and audiences.


## Deliverables

1. A formal definition of the canonical data model for representing
localizable message strings.

2. A formal definition of the canonical syntax for representing the data
model, with well defined rules for handling text, special characters,
escape sequences, whitespace, markup, as well as parsing errors.

3. A specification for a one-to-one mapping between the data model and XLIFF.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we do same as before mot specify XLIFF or we can try all together define at least some base formats more than only XLIFF.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC, in the l10n tools world, XLIFF is the de facto standard format that they all support for importing/exporting, regardless of which other file formats they support. It's an open standard that is not vendor-specific. The core of it is implemented across most tools, even if some may attempt an embrace,extend,... strategy.

Copy link
Collaborator

@nbouvrette nbouvrette May 15, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd argue that XLIFF is probably the most complete (and complex) standard that is also not consistently adopted to the same extent across different products. It might be interesting to also consider the opposite file format (the simplest), which consist of only keys and values - for example .properties file. If we could support both then we should have a complete and flexible solution.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great point. It has been my experience as well that many vendors say they support XLIFF, and then it turns out that everyone supports a different subset of XLIFF.

4. A specification for resolving translations at runtime, including
interpolated data types and runtime errors.

5. A conformance test suite for parsing and formatting messages.


## Non-Goals

The following is a list of potential goals which are explicitly excluded from
the scope of the MFWG.

1. Design a _general interchange format_ for storing and transferring
translations. Instead, ensure compatibility with the existing interchange
formats.

2. Support _all grammatical features of all languages_. Instead, focus on
features most commonly encountered in user interfaces, textual, graphical
and spoken ones alike.

3. Create an _automated engine_ capable of transforming parts of speech in
a grammatically-correct fashion. Instead, allow interfacing with such
automatic and non-automatic engines from within the data model.

4. Create optimized and efficient _implementations of the standard_. Instead,
create specifications, compliance test suites, recommendations and good
practices to support implementors.

5. Build a _framework for localizing software_. Instead, design the standard
as a building block to be used by third parties to create localization
frameworks.