Schematron
- localization support
Schematron
- variable substitution support
SML-IF
identity attributes - localization support
Proposal
for localization support
Proposal
for variable substitution support
Localization support for
Schematron messages
Localization
support for SML-IF identity attributes
Variable
substitution support for Schematron messages
This proposal is intended to address defect http://www.w3.org/Bugs/Public/show_bug.cgi?id=4772
add keyword substitution in smlerr
localized messages?
The current SML spec under section 5.1, Localization of error messages, defines a new attribute, smlerr:localizationid to be used to identify localized ( translated ) strings. This attribute is defined as optional.
<xs:attribute name="localizationid"
type="xs:anyURI"/>
There are a few open questions with the current spec, the current proposal is trying to address:
1. The localizationid URI should first identify the location of the resource containing the translated string, then the string within that resource. Since most of the time the strings defined in a document are translated into the same file ( resource ) location, it is highly inefficient to have the same URI location specified on the smlerr:localizationid attribute for every string to be translated. Some sort of base used to identify the common resource should be available and it is not clear from the current spec description how to achieve this.
2. It is not clear how exactly this attribute will be used to locate a string. It is usually the case that separate translation resources are used for every locale ( the translation into Mandarin is most likely to be done by a person other than the one who is providing the Spanish translation; the two translations will be stored in different resources - files ). As a result, for an SML document to be used by different consumers, using different locales, the document should provide a localizationid attribute with a URI value that points not to a specific translation resource (file), but to a collection of translation resources for all supported languages. Some extra processing should be done to locate the desired file from the specified URI. In this case, appending the translated string id to the resource URI will increase the complexity in processing this information.
3. Based on a set of discussions within the initial working group, it was required to have translation support for IF model identity attributes as well ( name, description ). Since a producer may exchange an IF document with a consumer using a different language, the document should contain sufficient information for the consumer to process the name and description content in the consumer’s currently configured locale. ( it is assumed that this information is meaningful to the consumer or to users of the consumer, e.g. for display on a UI )
4. Use of the smlerr namespace could be read to imply that the attribute can only be used to translate Schematron error messages. SML should provide a consistent mechanism to provide localization information within an SML model, regardless of the localized string’s placement. The current approach is generic enough to allow this.
These are the scenarios used to define and verify the
validity of the current proposal.
Translation support for Schematron messages:
A model author creates a Schematron rule and wants to make these available to any consumer, irregardless of the consumer’s chosen locale, and without being aware of the locale that consumer is using.
For example, an English speaking model author creates a Schematron
rule which may be used by a Mandarin speaking user to validate the model. In
order for the Mandarin speaking user to be able to make use of the Schematron
rule, the model validation process has to emit a Mandarin version of the Schematron
messages and have a way to map these strings to the corresponding English
strings. This is what is usually referred to as localized strings.
In
addition to having string localization support, variable substitution should be
allowed for translatable text.
Example or Schematron error
message: Application {name} from {group} does not have high
security level.
The string can be reused as long as the name of the application
and the application group can be substituted. If variable substitution is not
supported, the string has to be translated multiple times, for every pair of ({name},
{group}) values, and even this alternative is only
useful when all the values are known statically.
Since an SML-IF document is an envelope packaging an SML
model for exchange purposes, it is necessary to be able to localize IF identity
elements ( description, name ).
This covers the scenario where the IF producer and the
potential IF consumer don’t use the same language. In this case, the document
should have enough information to allow the consumer to find the localized
strings appropriate for the consumer’s current locale.
Introduce a new attribute, smllang:locid with the type xs:QName
( replace existing smlerr:localizationid attribute
with this one )
<xs:attribute name="locid" type="xs:QName"/>
This attribute is defined on the element containing the string to be translated and identifies the location of the resource containing the translated string, as well as the id of the string to be translated.
A QName is a tuple {namespace name, local part}; the smllang:locid attribute will make use of this value as described below:
1. The Qname's namespace name is a URI that defines the location of the translated resource ( can point to a file containing the translated message, a folder containing a set of translated files or any other type of resource that can help locate the translation; It is implementation dependant how the processor finds the actual document containing the translated resources )
2. The Qname's local part contains the string’s key (a string that can used to uniquely identify the string into the translated file)
Note:
This proposal requires changing the namespace for the locid attribute from smlerr,to smllang. The reason for this change:
· Localization can be used for strings other than schematron messages ( SML-IF model identity attributes are discussed in this document )
· Even for schematron localization support, localization does not apply only to error messages; any type of messages can be the output for a schematron.
This document proposes using a new namespace, smllang, for the localization attribute. This is just a suggestion, any other value (including the sml namespace) is acceptable, as long as the namespace
reflects the fact that the attribute can be used on any type of message and not
only on error messages.
It is out of the scope of this spec to define how variable substitution can be achieved for translated strings. The spec should promote as a best practice the use of xsl:variable for achieving such support, as described in the example below.
1. Using a namespace other than smlerr for the localization attribute reflects that fact that localization can be applied on strings other then schematron ‘error’ messages.
2. Changing the localization attribute type from anyURI to QName allows a clear separation of the URI identifying the resource containing the localized message from the id of the message, used to identify the message within that resource. By having this separation, the following optimizations can be applied:
a. Reuse of URI within SML localized messages. The URI content is defined only once at the schema level, and then reused on every message, by specifying the URI namespace on the localization attribute
b. The processing of the localization attribute is done in two steps: first locate the resource using the QName namespace URI and next locate the string within the resource using the QName local part. The separation of the QName value in the namespace part and local part makes this processing straightforward and easy to apply.
<sch:schema
xmlns:sch="http://purl.oclc.org/dsdl/schematron">
xmlns:lg1="http://www.acme.com/translation/core"
xmlns:lg2="http://www.acme.com/translation/extension"
....
<sch:pattern
id="XPRequirementPattern">
<sch:rule
context="smlfn:deref(/core:source)">
<sch:assert
test="@os.version='XP'" smllang:locid="lg1:assertXPID">
The version of the Operating
System should be 'XP' instead of <sch:value-of
select="@os.version"/>
</sch:assert>
</sch:rule>
<sch:rule
context="/core:target)"
id="rule2">
<sch:assert
test="contains(name(.), 'capability.user')"
smllang:locid="lg2:assertServerID">
The database server requires a
user capability to function properly
</sch:assert>
</sch:rule>
</sch:pattern>
</sch:schema>
<smlif:model
xmlns:lg="http://www.acme.com/translation/core"
....
<smlif:identity>
<smlif:name
smllang:locid="lg:nameID">Model
Name</smlif:name>
<smlif:description smllang:locid="lg:descrID"> This document has
been last modified by John Doe at
<smlif:version>1.0</smlif:version>
</smlif:identity>
…
</smlif:model>
1. In an XLIFF (http://docs.oasis-open.org/xliff/v1.2/cs02/xliff-core.html)
document:
<? xml version="1.0" ?>
<xliff version="1.0">
<file original="sml.xml"
source-language="en">
<header>
<skl>
<external-file href="acme.skl"/>
</skl>
</header>
<body>
<trans-unit id=" Name1ID ">
<source xml:lang="en"> Model Name</source>
</trans-unit>