My question is if we need to specify the kinds of localization we intend this to cover. For example, if we want to support localization of variable text for games that required mechanisms for including things like gender and number agreement and so forth, the core will have a bunch of things that won't exist if we're more limited. It seems to me that the core should cover items common to many types of localization, while leaving things like gaming, multimedia or other more specialized areas for modules. (But see my question about the intention of modules below.)
We don't specify the kind of localization to do. The core has containers that are enough for the simplest document formats. We offer holders for plain text and basic inline elements. Specialization is out of scope.
As a result I would suggest that the core specify that we are going to support localization of documentation and general software, not everything that might be called localization.
That's OK for me.
…can be enhanced with…
Not certain that “enhanced” is the right term. How about “, can be completed with…”?
Fine, "completed" is a better term.
…the translation of the extracted text and allows the generation of translated versions of the original documents.
The namespace that corresponds to the core of XLIFF 2.0 is "urn:oasis:names:tc:xliff:document:2.0". All elements and attributes that belong to the core will be documented in the body of the XLIFF 2.0 specification
Perfect.
A module is an optional set of XML elements and attributes that stores information about a process applied to an XLIFF document and the data incorporated to the document as result of that process.
Do modules only store information about a process applied to an XLIFF document?
No, it also contains data that is added after the XLIFF is created. If you apply TM or MT to an XLIFF file, you will need containers for the matches retrieved by the process.
Let's say that I create a module for variable text for games.
An individual doesn't create a module, the XLIFF TC creates a set of standard modules that support most common cases. One of our goals is to avoid customization that damages interoperability.
Such a module may add additional constructs to the XLIFF document that are fundamental to the data to be translated, not a representation of a process applied to the document. I’m not trying to be pedantic with this question, because I think it's rather important: is a module only something applied to a core, or can it be a specialization of the core for a particular purpose from the beginning?
A module defines elements that are not essential for creating an XLIFF file from common documents. If you are interested on gaming, you can add a request in the wiki for creating a module that defines the elements and attributes that the core lacks. The schema for gaming and the corresponding documentation can be added to XLIFF 2.0 if the TC agrees.
This language might imply that the starting point is always a pure-core XLIFF file.
Yes, that's right.
If, however, the module can represent a specialization for something like gaming with requirements that cannot be represented in a core-only format, it has implications for interoperability and they may not be optional at all: you couldn't just ignore the modules in the file and do some processing and the module would go beyond just embedding some tool-specific data in the XLIFF file. So if I create a variable text module like this, have I violated the fundamentals of XLIFF?
It is OK to have modules that create specializations. XLIFF enabled tools will have to support core, support for specializations would be optional.
Each module defined for XLIFF 2.0 must have its grammar defined in an independent XML Schema with a separate namespace.
Good.
All elements and attributes that belong to a module will be documented in a dedicated annex of the XLIFF 2.0 specification.
Can we change “that belong to a module” to “that belong to officially recognized modules”? We don't want anything that might appear to obligate us to include private modules in an annex to XLIFF 2.0. While I would hope people would document their modules publicly, we cannot make them do so.
There will not be private modules. We agreed some time ago to drop extensibility.
Those companies that created custom extensions had a chance to submit their schemas and documentation for analysis so we can contemplate their needs in XLIFF 2.0. So far we received several schemas but no documentation. It is not easy to consider particular needs when creating a draft schema for XLIFF 2.0 if interested parties don't provide information.
Despite my questions, I think this is an excellent start of something very important. Thank you Rodolfo.