I18N ITS WG F2F

<r12a> SR: Difference between translation and localization?

<r12a> RI: No difference

requirement on translatability

<r12a> "From Requirement to Solution" examples: Taking two of the important requirements and proposing a solution for them. Example 1: Indicator of translability (prepared by Yves)

<r12a> email sent with initial proposal

<r12a> we could use tag sets, mapping, etc

<r12a> also could do on schema or content level

<r12a> two aspects of translatabliliy:

<r12a> 1. sth is translatable, eg. p element

<r12a> 2. normally translatable element is in some case not translatable

<r12a> in case 1 all elements, in case 2 specific elements

<r12a> two main ways to do this:

<r12a> 1. use existing markup, map its concept of translatability to original format

<r12a> 2. use an its tag to provide the information

<r12a> two levels:

<r12a> 1. schema

<r12a> eg. in xml schema you can define the type of an element

<r12a> nothing already exists

<r12a> solution would be to use a namespace with a 'translate' attribute

<r12a> if you extend the relaxng scheme it will no longer validate

<r12a> FS: the processor will throw out any unknown name spaces will be removed

<r12a> ... but may be different for schema

<r12a> ... example for xml schema would be better if we used xs:annotation element

<r12a> [[ see yves mail at http://lists.w3.org/Archives/Public/public-i18n-its/2005JulSep/0123.html ]]

<r12a> translation tools would have to scan the schema to discover translatability

<r12a> ys: we need to add process information

<r12a> fs: this needs to be schema specific

<r12a> ... maybe for dtds default values would be more useful

<r12a> ys: another problem is that dtds are not supplied with data during translation

<r12a> sr: we may need to use schematron to enable us to specify context, eg. a p in a div of class x shouldn't be translated

<r12a> cl draws on the whiteboard a number of scenarios

<r12a> 1. schema exists

<r12a> 2. schema exists and is modifiable

<r12a> 3. schema format

<r12a> 4. instance referencing the schema

<r12a> 5. internal subset

<r12a> cl: we need to bear these scenarios in mind

<r12a> ... we should also look at abstract representations before getting to specific schemas

<r12a> fs: it would be nice to use types in xml schema for translatability

<r12a> sr: but you can only have one type at a time, so that would not work well

<r12a> cl: we may have more values that yes and no for translatability

<r12a> ... others include: "must not" , "must", "may" (opens door to resource or process related decisions), "x-"

<r12a> ... each of the 4 values may have additional information: esp for may, could have priorities

<r12a> sr: you could combine all this in on numeric value where 0 means no and 5 means yes and in between is may

<r12a> cl: may also need information about origin of translatability information

<fsasaki> CL: How about the values of the trans req?

<fsasaki> YS: Localization is major thing

<fsasaki> .. translation is an aspect of it

<fsasaki> RI: Another ex, telehone numbers

<fsasaki> .. not translation

<fsasaki> SR: two questions

<fsasaki> .. what rules are important for translatability?

<fsasaki> .. how do you specify the rules?

<r12a> also discussion about need for 'localize'-like flags

<fsasaki> SR: Need to make sure "translatiablity" is more than "yes" or "no"

<fsasaki> CL: Need to discuss both aspects

<fsasaki> CL: What should be translatable?

<fsasaki> .. elements, attributes, PI, comments, ...

<fsasaki> CL: the solution should be applicable for all such kinds of information

<fsasaki> Yves: what comes next?

<fsasaki> FS: Summary?

<fsasaki> Yves: Distinction between various kinds of information

<fsasaki> .. e.g. localizability vs. translatability

<fsasaki> .. various values e.g. for translatability, e.g. "may be" or "must no"

<fsasaki> .. also the technologies for realization

<SebastianR> <s:rule context="tei:moduleRef">

<SebastianR> <s:report test="@key">

<SebastianR> <its:translatability>

<SebastianR> <resp>Yves</resp>

<SebastianR> <date>2005-09-19</date>

<SebastianR> <rule>must</rule>

<SebastianR> </its:translatability>

<SebastianR> </s:report>

<SebastianR> </s:rule>

<fsasaki> FS: technologies?

<fsasaki> .. schema annotation

<fsasaki> .. information from a foreign language in a schema

<fsasaki> .. rule language like schematron

<fsasaki> SR: wrapping the schematron language

<fsasaki> .. in schematron you just have some text that comes out as a message

<fsasaki> .. SR reporting on the rule language example

<fsasaki> RI: implementation of localization properties?

<fsasaki> .. if we are using schematron etc. for localization properties, that is not our business

<fsasaki> .. localization properties: localization groups would define a set of rules which tell you what to do with a schema

<fsasaki> .. theoretically, we said we want to define translatability in the schema

<fsasaki> .. two aspects

<fsasaki> .. one is defining for a whole set of elements

<fsasaki> .. one is overriding of that for a content author

<fsasaki> .. another requirement: existing schema

<fsasaki> .. versus a schema which will be created

<fsasaki> .. also it has to very simple to do

<fsasaki> .. so I would prefer numbering instead of tripe notation

<fsasaki> CL: it is not just authors and schema authors, but people working in the localization reality

<fsasaki> .. they want to say s.t. like "all graphics should not be localized"

<fsasaki> .. there are three places doing this:

<fsasaki> .. external document which says "all graphics should be translated"

<fsasaki> .. it might be the schema or s.t. else, e.g. a stylesheet

<fsasaki> .. another part: a special section, like for styles in the css case

<fsasaki> example: <meta element="p" translate="no"/>

<fsasaki> .. sometimes we want to say s.t. about specific p instances

<fsasaki> .. for each of the places you could use different ways of expressing the information

<fsasaki> .. e.g. you might need xpath for some places

<fsasaki> RI: stylesheet language is different from a markup scheme

<fsasaki> .. the localization industry can invent that

<fsasaki> YS: A lot of things should be defined in the schema

<fsasaki> .. of course, we need some kind of CL examples

<fsasaki> .. but there is a core level at the schema

<fsasaki> SR: A schema cannot dissallow comments and PIs

<fsasaki> .. it is inherent in XML

<fsasaki> SR: Is context very important? I.e. that only commments are translated?

<fsasaki> .. schema is an akward place to do it?

<fsasaki> YS: generally it is an exception that has to be specified

<fsasaki> RI: should we address this at the schema level?

<fsasaki> .. if we end up with a localization property file

<fsasaki> .. about e.g. translatability

<fsasaki> .. how about just a mechanism in the schema for the content author

<fsasaki> Yves: there are also existing schemas

<fsasaki> .. for example they know that <code> is translatable

<fsasaki> RI: If I write a DTD

<fsasaki> .. I could make the default attribute for code "no"

<fsasaki> CL: one solution is on the table, which RI indicated

<fsasaki> .. if e.g. SAP wants to assure that all new schemas have this information

<fsasaki> .. we could implement it with the elements / attributes described

<fsasaki> .. some people might want to describe it externally

<fsasaki> .. but that is different

<fsasaki> SR: we can have both

<fsasaki> .. a complex and a simple solution

<fsasaki> .. if you have this "log" element (described by CL) which is quite complex

<fsasaki> .. there is no harm in w3c to suggest it

<fsasaki> RI: we might define it

<fsasaki> .. Yves and Tim are involved in other standard bodies which also work on that

<fsasaki> .. RI describes the new development of the Unicode conference

Requirement on international text

<fsasaki> Some material:

<fsasaki> http://www.w3.org/International/its/possible-implementations/

<fsasaki> http://www.w3.org/International/its/possible-implementations/

<YvesS> felix prepared templates

<YvesS> http://www.w3.org/International/its/possible-implementations/datacat-impl-combined.html

<YvesS> description section, implementation per type of schema and modularization

<YvesS> felix mostly copied data from Ruby markup

<YvesS> .. saw the occasion here to work on the structure of the document recommendation

<YvesS> .. various audiance care about difference things

<r12a-sophia> http://lists.w3.org/Archives/Public/public-i18n-its/2005JulSep/0123.html

<YvesS> ..helpful to have spec separated by audiences or type of usage.

<r12a-sophia> http://www.w3.org/International/its/possible-implementations/

<YvesS> example: ITS module for putting in in schema

<YvesS> .. another to put in document, etc.

<YvesS> ..helpful to have fixed modularizations (e.g. XHTML+ITS or DocBook+ITS, etc.)

<YvesS> ..danger if modularizations not defined.

<YvesS> RI: that means taking to the groups like XHTML, TEI, etc.

<YvesS> FS: yes.

<YvesS> ..as ongoing work. better one group does the integration

<YvesS> ..the rest are various implementations

<YvesS> ..all variations are link back to datacat definition

<YvesS> ..for schemas:

<YvesS> ..one implementation with named type one without

<YvesS> ..we need to decide what designpattern we want to use.

<YvesS> ..also a definition for Relax-NG

<YvesS> ..with link back to datacat

<YvesS> ..so that is a way of linking abstract ITS concepts to implementations

<YvesS> ..independant datacat from implementation is important

<YvesS> ..examples of modularization: docbook, etc.

<YvesS> .. the prose version (http://www.w3.org/International/its/possible-implementations/datacat-impl-onlyprose.html)

<YvesS> ..defined only datacat.

<YvesS> ..last examaple: use namespaces

<YvesS> http://www.w3.org/International/its/possible-implementations/datacat-impl-ns-sections.html

<YvesS> ..do we want to use this technology or not (it's new and being implemented)

<YvesS> .. (talking about NRL)

<YvesS> .. two approaches for integration

<YvesS> .. a) by being imported in the host namespace directly. But no distinction between the original namespaces.

<YvesS> ..b) with NVDL

<YvesS> (being standardized by ISO)

<YvesS> FS: it will take a while before something is really used.

<YvesS> YS: any comments?

<YvesS> SR: key thing: you define a meta lamguage

<YvesS> FS: yes

<YvesS> SR: basically: the thing is to decide what to name things at the instance level.

<YvesS> FS: language is define here:

<YvesS> http://www.w3.org/International/its/possible-implementations/datacat-impl-separated.html#d2e145

<YvesS> FS: Ruby is just an example.

<YvesS> RI: any language already exists?

<YvesS> FS: in case of ruby, yes.

<YvesS> SR: do we have a master schema for Ruby?

<YvesS> FS: we could use an abstract definition, with prose definition, and create schema implementation

<YvesS> RI: what about Masayasu Ishikawa language?

<fsasaki> http://www.w3.org/People/mimasa/test/schemas/NOTE-ruby-implementation

<YvesS> ri: can you define formalism for it?

<YvesS> fs: but we may not need it?

<YvesS> RI: the question is how we would do it otherwise

<YvesS> SR: doable for small set not large ones

<YvesS> CL: summary is: we'll define something.

<YvesS> .. then how should we publish it

<YvesS> FS: also how do we implement it

<YvesS> FS: the danger is to branch off the implementations

<YvesS> RI: but the users want optimization

<YvesS> FS: compared to TEI ITS should be simple.

<YvesS> RI: seems that it would be like a superset of all schema languages

<YvesS> CL: ODD seems a similar solution

<YvesS> FS: the question is do we need schema language-specific properties for our req

<YvesS> SR: another approach is to work with XML schema (standard for W3C)

<YvesS> FS: but other people use other schema language..

<YvesS> RI: one aspect is to try to get consistency.

<scribe> scribe: felix

CL: finished up a formal bnf like notation for data categories
... we have features and values for data categories
... I integreated - during the break - also the ruby requirement

summary of the day

YS: we saw different levels which need to be addressed
... schema level, document level
... we discussed ways of doing that; we did not discuss mapping so far

CL: we said that the data category "localazibility" is too broad

YS: we said that there are more values which are needed as well
... two extremes
... a simple namespace about translatability in a schema
... or as the other extrem to define a different language for specific elements / attributes
... or to be used in a document directly

CL: I suggested three possibilities to connect info to instances
... externalization (e.g. external stylesheet)
... at the top of the file
... or for a specific element

YS: We looked at different cases for the problems
... a schema exists / no schema exists / a schema exists, but is not modifyable
... an instance refers to a schema / refers not to it
... relying on all these circumstances, there is a different solution
... afternoon:
... we discussed ruby definition (annotation markup)
... ruby as an example
... felix presented not a solution for ruby, but how to specify the solution in a specification in a document
... making sure that we seperate the formal (abstract) description from the implementation
... we talked about how to automatically convert the abstract description into schema language specific implementations
... e.g. RELAX NG / XML Schema / DTD
... we discussed the approach of xhtml modularization (Masayasu)
... then we had the discussion on the TEI approach

RI: what are the decisions so far?
... we decided the separation of abstract definition from implementation
... we liked the structure of the document template
... we would look into doing generating the implementation automatically
... questions so far: is it possible to do this automatically?

YS: other questions?
... we decided to take ruby, go through it manually, make an implementation in each schema language
... then we use the TEI approach and see if it is possible also automatically

RI: we had the discussion with CL
... it has a few things to do with the schemas, but mainly with the instance documents
... made the parallel with the stylesheet and the localization information

CL: we talked about a formal representation of information for localization instruction
... e.g. indicator of translatability, constraints, ...
... we also talked about a formal representation of capturing the localization instruction
... we need a way to select markup to which s.t. applies
... and we need to tell what should happen to that markup

<chriLi> the formal representation is here:

<chriLi> localizationInstructionSet ::= localizationInstruction+

<chriLi> localizationInstruction ::= selector declaration

<chriLi> selector ::= XPath expression

<chriLi> declaration ::= '{' feature-value-expr '}'

<chriLi> feature-value-expr ::= indicatorOfLocalizability | ruby | constraint | equivalence | ...

<chriLi> indicatorOfLocalizabity 'localize' ':' 'must|mustNot|maybe|x-'

RI: another question we talked about
... whether we should define translatability for the content author or for a broader audience

felix document on the implementation of ruby: http://www.w3.org/International/its/possible-implementations/

SR: You always need a third party file
... you don't want the tools to go back

RI: what CL described is the localization properties, i.e. its container and the properties themselves

YS: To some degree that is understandable
... defining just the container would not be enough

RI: We are likely to suggest things that content authors could do

YS: Currently you cannot generate localization properties from a schema

CL: If you spell the syntax out
... e.g. a syntax for constraints e.g.
... where we would go from my abstract description:
... example: "indicator of loclizability"
... for this specific part we generate an xsd
... that schema we generate out of this
... somebody who uses this for his schema
... could then include it into the schema

SR: there are two options: defining a schema module vs. defining an extension to the schema language

YS: information about the fact that a certain "p" is not translatable cannot be expressed in that way
... So the user needs to define what is translatable and what not
... the mechanism CL described is for the instance, right?

CL: suppose I finished my description in the ABNF syntax
... now I want to use that information
... I declare an element with xsd:element, using an imported ITS schema

YS: a tool would be able to go through the schema and generate default values, also for xsd

SR: depending on attributes might break several things

CL: the attribute we are using
... you can also use an element

SR: if you take the simple case of an attribute you don't want to be translated
... how can you express it with your approach?

CL: you can have a container in the instance

SR: I don't want to change my instance

YS: you could take the list of what you are defining in a specific namespace?
... so you could use the same syntax, just with different values
... we would need a 1:1 map between the different purposes
... e..g the localization developer, the content author, ...

fs: described a common solution , its:def element with its:defs children for various purposes

Ys: Action items?

<scribe> ACTION: Felix to make an example for the its:def element [recorded in http://www.w3.org/2005/09/19-i18n-minutes.html#action01]

<scribe> ACTION: SR to create an ODD example [recorded in http://www.w3.org/2005/09/19-i18n-minutes.html#action02]

Ys: these solutions don't solve our simple problems
... should we try to solve the simple problems?
... e.g. specify for a whole document "yes" "no"
... e.g. an xhtml file with a few sections which are to be flagged as non translatable
... (for some users that might be too complex)

CL: equivalence might be another "simple" problem
... e.g. we define a its "no" translate
... for a dita you might define "this is xxx in dita"

<scribe> ACTION: YS to check for overlap and differences and between translation req implementation and the ruby req implementation [recorded in http://www.w3.org/2005/09/19-i18n-minutes.html#action03]

<scribe> ACTION: FS to check for overlap and differences and between translation req implementation and the ruby req implementation [recorded in http://www.w3.org/2005/09/19-i18n-minutes.html#action04]

YS: only bidi and ruby needs structural changes in the document, right?
... you might not use a different namespace for that maybe?

RI: translation tools need to deal with that things

YS: with mapping it could be realized
... i.e. define an equivalence

CL: we could just say "please use the ruby markup of xhtml 1.1"

YS: some kind of equivalence would be useful, hence we need mapping definitions

RI: I was thinking of mapping in terms of localization properties

YS: we have some requirements that are structure specific, we need a solution that is not covered here

[comment for myself: think of this while preparing its:defs]

RI: what CL proposed are localization properties
... we are responsible to provide a container, not too much more

YS: we should provide more than a container

RI: we don't have to say what the language is which fills the container

YS: maybe we need to specify we abstract version of a container for localization properties

closing today's work

<chriLi> [comment for myself: Suggestion from Sebastian: Use "mustLocalize mustNotLocalize maybeLocalize x-localize-y" rather than "loc:must" etc.; helps to put in correct values]

agenda for tomorrow:

RI: discussing the translatability req more
... i.e. the values of the translatability
... "translatability information" or "translate: what does it mean"?

YS: we need to talk about attributes
... how to address translatability or s.t. else for attributes

CL: another topic: how to represent a simple localization information with ODD
... also how to use the equiv element from TEI (might help with mapping)

FS: and the its:defs element

Order of tommorros work:

1) start with the examples from SR and FS

2) how to specify the info for attributes / PIs / ..

3) translate: what is it?

4) representation of constraints

FS: how about mapping?

5) mapping