See also: IRC log
<r12a> SR: Difference between translation and localization?
<r12a> RI: No difference
<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
<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
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
<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