[This is a work document for ITS Jul-27 teleconference]

List of changes in the Requirement documents:

01- International Tag SetMarkup Requirements

Note: Christian proposed "Internationalization/Localization Markup Requirements", after discussing it, Felix, Richard and I thought the change above would be better (simpler and encompassing both i18n and l10n).

02- This document aims at defining the requirements for a set of solutions that would address the main challenges and issues of internationalizing and localizing XML documents.

03- The solutions are expected to take the form of include several aspects: a specialized namespace that XML users can include in their own documents, a set of guidelines to apply when using existing XML technologies, and possibly other mechanisms.

04- This is done through a process called localization, where original material is translated and adapted to the target markets audience.

05- From the viewpoints of feasibility, cost, and efficiency, it is important for the original material to be ready suitable for localization.

06- Such approaches are not meant to describe the configuration settings (i.e. localization properties) of localization tools for XML content.

07- terms that either should not be translated or translated using a pre-existing terminology list

08- The same markup can be used further down the project, during translation at later steps in the translation process, to help the translators match up the source terms with their agreed-upon translations.

09- The use of a common set of markers allows for better re-usability of the information across the different steps of the localization process and across the various tools used to facilitate ithat process.

10-2.3 Software Resources Development

11- For example: Examples of this, would be UI resources and message files, comments in the source code to generate documentation, or even temporary XML storage generated from proprietary formats for the time of the localization.

12- A software developer often needs to provide localization-related information along with the resources that will be translated.

13- For instance, he or she may needs to indicate that a string has a maximum length because the program reads processes it using a fixed-length buffer.

14- A span-like element is also extremely useful for marking language information in source files that translation tools can also be used to determine which translation process to use for each given section of text

15- Several of the following requirements are illustrated with XML code samples using a yet-to-be-defined ITS namespace. The names of elements and attributes and the namespace prefixes used in these examples. These names are completely arbitrary and are not intended to represent the appearance of the actual namespacesolution. The solution also may or may not be implemented as a namespace.

16- The xml:id attribute [XML ID] may be a means to carry the unique identifier.

17- In order to simplify the parsing process by documentation and localization tools, there should be declaration of a language/locale that is applied to the whole document as well as externalized content.

18- Therefore when a Japanese index item is created, it should be accompanied with a phonetic string, called Yomigana.

19- Here are sSome reasons why this type of markup may require special attention:

20- Examples of issues are as followings Here are some examples of these type of issues:

21- The mechanism should also allow for specification ofto specify exceptions within exceptions.

22- For example, within the elements of an SVG document, which are generally not translatable, it should allow one to specify that <text> is to be translated, but also that some occurrences of the <text> element (e.g. with an attribute translate="no") are not to be translated.

23- Here are some examples of this :

24- The mechanism should provide a way to delimit a portion of the content if such a mechanism does not exists in the original vocabulary (so parts of athe content could be set to be translatedmarked as translatable or not).

25- Any solution for oneSolutions for any of the ITS requirements must take in account these potential drawbacks and offer implementations that has ave limited impact ion the original document and on the content models in the original schema.

Changes in Example:

Removing the 'its:' prefix in examples: Richard proposes to remove altogether the its: prefix in the examples for the following reasons:

• it suggests that we are only developing a solution involving namespaces, but DTD users cannot use namespaces so this is not the case.
• to use the same prefix all the time also sounds like we might be developing a fixed namespace, like xml: - which is also not true (note that the prefix could be anything the user wants, as long as it is declared properly).
• most important: we shouldn't be proposing solutions here - the requirement is to simply have available an element or an attribute that fulfills a specific function. Using a namespace in the example turns that into an example of how that could be implemented, rather than an example of what is needed. People who are able or want to use namespaces will recognize that they should be able to do that.

26- The Java statement <code><its:span-notransspan trans="no">System.out.println("<its:/span-notrans/span>Hello 
World<its:span-notransspan trans="no">");<its:/span-notran/span></code> prints the text "Hello World!" to standard output.

Note: Change <span-notrans> to <span trans="no"> because <span-notrans> is more an example of no-translation tag, than a specific case of a generic <span>.

27-

<its:purposeSpec>
 <servesPurpose origVoc="index" its="term"/>
</its:purposeSpec>

28-

<table its:translate="no">
 <tr>...
</table>

29-

<its:notrans>
 <table>
  <tr>...
 </table>
</notrans>

30-

<its:info>
 <its:mapping target='quote' its='notrans'/>
<its:info>
...
<para>The motto of Québec is:
 <quote>"je me souviens"</quote>.</para>

31-

<doc>
 <its:info>
 ...
 </its:info>
 <header>...
 <body>...

-end-