See also: IRC log
<scribe> scribe: Felix
<scribe> scribeNick: fsasaki
http://lists.w3.org/Archives/Member/member-i18n-its/2007OctDec/0000.html
Felix presents the classification of issues and asks people if they agree on the classification
and what to do during the f2f
we try to do class 1 and class 2 of issue during f2f
we decide not to make a detailed time schedule
and just do as much as we can do until December
Felix: "in Sec 5: The following XML applications are discussed:", rather say "vocabularies" instead of "applications"
Yves: : replaced "markup schemes" with "markup schemas" through the whole document
Jirka: propose to drop "conforming to International Standard ISO 8879"
Felix: fine by me
Jirka: statements liek
"non-conformant" in "A non-conformant XHTML 1.0 documen" are
hard to understand for many readers
... propose to change title or description of example
... "XHTML with ITS markup"
"There are three ways to use ITS with XHTML and keep the XHTML document conformant:"
Jirka: this statement is not
correct
... rather "there are three ways to integrate ITS into
XHTML"
Richard: put example 55 in a separate subsection paralell to 5.1.2 and 5.1.3
Jirka: "URI" in table has sometimes spaces, sometimes not
We just need Felix to go back to XHTML2 WG and wait for feedback
Yves: this section has no conformance statement
Jirka: is missing, needs to be added
Richard: the section does not tell you how to work with NVDL
Jirka: you need to have a validator which processes NVDL
Richard: good to have further information on that
Jrika: I'll write 1-2 sentence and give a link to NVDL tutorial etc. site
Yves: proposal to 5.1.2 and 5.1.3 and new subsection about "using ITS rules for integrating ITS into XHTML" as subsections of 5.1.1
Yves: maybe order of "integration" and "assocation" sections could be reversed, since often you think abbout association first
Richard: in 5.1.4, need text to say "this is one way of doing this, but rules are relevant to all of the three appraoches in the following section"
Yves: 5.2 misses "ITS related to TEI"
<Jirka> Example 65: > If you look at example 47 it references span.attributes pattern. But
<Jirka> > this pattern represents ITS attributes in no namespace. But we have
<Jirka> > previously decided that ITS attributes should be in ITS namespace when
<Jirka> > present on non-ITS elements.
<Jirka> >
<Jirka> Sorry for taking _so_ long to look at this. That example should read
<Jirka> <attRef name="its-att.local.with-ns.attributes"/>
<Jirka> which does provide the right attributes in their namespace.
Jirka: above is about example 65
Felix: should we use "normal"
XMLSPEC dtd or the XMLSPEC dtd modified in i18n activity?
... currently we do the later, so we have a lot of rules to
associate e.g. XMLSPEC "translate" attribute with ITS
"translate" attribute
Richard: say at the
beginning:
... you could either use XMLSPEC i18n, or the normal
XMLSPEC
... <its:termRule selector="//qterm" term="yes"/> : qterm
might not be used for terms, rather citations
... better get XMLSPec ITS compliant, and show how we did
that
... and show how to get from XMLSPEC > XMLSPEC i18n
... and get rid of the "old" XMLSPEC i18n
Felix: +1
... I'll rework this section
Richard: and need to update XMLSPEC i18n
Need also mention of ruby and "elements within text"
Yves: working on it, integrating feedback from DITA folks
Jirka: "The declarations above cover different versions of DITA.": which version?
Yves: need to name the version
Felix: on example 70:
... Why is this called”translatability flags”? Same question
for other “flags” below.
Yves: I'll use s..t else
Felix: on example 69
... %its-rules calls the %NS entity: <!ENTITY % its-rules
"%NS;rules">. We should rename that entity to %its-ns and
%its- rules accordingly: <!ENTITY % its-rules
"%its-ns;rules">
Yves: probably DITA folks made same comment
Felix: I *think* for this task we will need provide ITS namespace declaration like xmlns:its CDATA http://www.w3.org/2005/11/its. See also http://www.w3.org/TR/2007/REC-its-20070403/its.dtd .
Yves: again DITA people gave that feedback, I'll just ned to finish the description
Felix: Example 71: Example of Glade document, a very large example
Yves: could remove some items
Richard: or point only to the external file
Felix: "While Glade does offer
support for some of the ITS features,"
... Examples or an exhaustive list would be good.
... 5.5.2: We need to get feedback from the glade spec
developers on this section
Yves: got some feedback
Felix example 72:
scribe: <its:locNoteRule
selector="//*[@translatable='yes']
... this should be and <its:locNoteRule
selector="//*[@translatable='yes' and @comments]
Yves: paragraph 1 is biased
Felix: "Not all ITS local
attributes are added into schema as DocBook already provides
its own means for specifying directionality of text"
... Maybe an extensive list of what is not added?
Jirka: DocBook "dir" attribute is available
Felix: propose to list this here
Yves: first paragraph after
example 73:
... term "flattened" may be not clear
Jirka: will think about better naming
no need to go through here
Yves: propose to split in active participants and current participants of WG
Felix: +1
- Add a paragraph in the introduction about the target documents: XML documents which contain natural languages. Many BP pertain only to such documents.
- ask reviewers explicitly for BP not covered by this document (in status section and mail to W3C chairs list, www-international list).
- Subsections of sec. 5, starting " Relating ITS to", should be called "Associating Markup with ITS"
Felix: some issues for the bottom of our list
ISSUE-1 Felix will do that
ISSUE-2 - Introduction
discuss this in category 2)
discussed ISSUE-2, leave it to the editors
ISSUE-3 Sec. 1.1 Who should use this document
nothing to discuss
ISSUE-4 Sec. 1.2. How to use this document
create subsections "content authors" and "developers", or bold (if not subsections) - agreement, editors will implement that
"Need references for the formats mentioned" - agreement, if we don't find references, we drop the thing
""NVDL, which can amongst others ..." This paragraph needs to be made clearer"
<scribe> ACTION: Jirka to rework pagarahh on NVDL in sec. 1.2 [recorded in http://www.w3.org/2007/10/03-i18nits-minutes.html#action01]
<trackbot-ng> Created ACTION-25 - Rework pagarahh on NVDL in sec. 1.2 [on Jirka Kosek - due 2007-10-10].
""If you are working with XSD, your options depend on the question whether the schemas involved define target namespaces (techniques such as working "chameleon" or proxy" schemas may be considered as solutions in certain cases)." Need to go back to Christian with above paragraph and figure out what he wanted to say
<scribe> ACTION: Christian to explain "If you are working with XSD" paragraph in sec 1.2 [recorded in http://www.w3.org/2007/10/03-i18nits-minutes.html#action02]
<trackbot-ng> Created ACTION-26 - Explain \"If you are working with XSD\" paragraph in sec 1.2 [on Christian Lieske - due 2007-10-10].
In general on material about on creating / modifying schemas: language / formulations need to be reworked
Yves will take of that (as an editor)
ISSUE-5 Sec. 2 When Designing an XML Application
bullet list before table can be removed - done already
list of BP should be just BP, without saying "Best Practice 1: ..." - agreement,
<scribe> ACTION: Felix to modify XSLT for the table in sec. 2 [recorded in http://www.w3.org/2007/10/03-i18nits-minutes.html#action03]
<trackbot-ng> Created ACTION-27 - Modify XSLT for the table in sec. 2 [on Felix Sasaki - due 2007-10-10].
Felix proposes a note before the table: "Note that the column "For Existing Schemas and DTDs" assumes that your existing schema already provides internationalization related functionality. That is: there is no need to use [ITS 1.0] markup directly, but the existing markup only needs to be associated with [ITS 1.0] following sec .5.5 "Associating ITS Data Categories with Existing Markup", or...
scribe: the mechanisms for pointing to existing information described in sec. 5.2.1 of [ITS 1.0] need to be applied."
Richard: "adding new functionlaity " vs. "adapting existing functionality". as column names
note and table column name renaming agreed, note needs to be modified
ISSUE-6 Best Practice 1: Provide xml:lang to specify natural language content
"Note: If not the language of the content, but a natural language value as data or meta-data about something external to the document has to be specified, an attribute ifferent from xml:lang (like hreflang in XHTML) should be used." This paragraph is German English, needs to be internationalized
again will be left to the editor
notes in this sec. are mostly paragraphs. Need to decide what stays as a note, what becomse a paragraph. Probably all except hte 3rd one will be paragraphs.
agreed, editor will implement that
HREFLANG is not used often. We need a better example here. http://www.w3.org/International/questions/qa-when-xmllang (URI has examples for HREFLANG issue)
If somebody comes up with a different example, we use that, otherwise we use the HREFLANG example
last sentence change proposal for the "Make sure" note (last note): "The XML Schema built-in data type language does not allow empty values. However, the declaration for xml:lang in the XML Schema document for the XML namespace at http://www.w3.org/2001/xml.xsd does allow for empty values and therefore can be used."
agreed
need real "HOW TO DO THIS" mateiral for various schema languages, see e.g. 4.2.1 4.2.2, and 4.2.3
agreed with adding a pointer to these subsections
example 2 "Non-standard way of declaring language information". Discussion whether this should be reworked. Problematic example, since the inheritance behavior of xml:lang is not given. Proposal: add a remark about this fact. Example 2 is problematic, see "Best Practice 12: Use multilingual documents with caution.". Needs to be made clear.
agreed for now, move on
Example 3. "Use the following rule to specify that the langcode element holds the same values as the xml:lang attribute." Add "and applies to the text element".
agreement
ISSUE-7 Best Practice 2: Provide a way to specify text directionality
"the user to specify the base writing direction of blocks, embeddings and overrides for the Unicode bidirectional algorithm." This might need a check from Richard.
<scribe> ACTION: Richard to check the statement "the user to specify the base writing ..." statement in BP 2 [recorded in http://www.w3.org/2007/10/03-i18nits-minutes.html#action04]
<trackbot-ng> Sorry, amibiguous username (more than one match) - Richard
<trackbot-ng> Try using a different identifier, such as family name or username (eg. rishida, frichard)
<scribe> ACTION: rishida to check the statement "the user to specify the base writing ..." statement in BP 2 [recorded in http://www.w3.org/2007/10/03-i18nits-minutes.html#action05]
<trackbot-ng> Created ACTION-28 - Check the statement \"the user to specify the base writing ...\" statement in BP 2 [on Richard Ishida - due 2007-10-10].
ISSUE-8 Best Practice 3: Avoid translatable attributes
rewrite first sentence of first bullet point of "Why do this" section - Yves / editors work
on example 7: "For example, if it can be avoided, do not allow this" rather than "do not allow this:", since the example is so common
agreement
"why do this" there is the need to mention inline labeling of language in the "why do this" section.
agreement
Don't understand the note before "resources" section
note will be moved below example 8
"Normally, those markers are elements, but elements cannot be used within an attribute value." Propose to say "Normally, those markers are segmented via element oundaries, but elements cannot be used within an attribute value."
Yves: will rework that note
ISSUE-9 Best Practice 4: Indicate the translatability of elements and attributes
issue in example 9: element with alt attribute should not be in del element
Jirka will fix it
ISSUE-10 Best Practice 5: Provide a way to override translatability information
before example 11 it says "Both have the same semantics as its:translate,". Propose to say "Both have the same semantics as its:translate, that is: the translation information applies to element content, including child elements, but excluding attribute values."
example 11 needs a 4fh rule which would be identical to 2nd rule, but covering translate="yes"
both fine
difference between BP 4 and BP 5 needs to be clearer
we move this to the "class 2" issue discussion
ISSUE-11 Best Practice 6: Provide text segmentation-related information
mixed content refers to element declarations. This BP can be used without a schema at all and encompasses elements which contain only text or only elements, hence let's just delete mixed content.
agreement
ISSUE-12 Best Practice 7: Provide a way to specify ruby text
need to say s.t. about conformance levels of W3C Ruby spec
Richard: should be in "how to do
this" section
... need to tell people: you can do simple or complex
ruby
... this applies to new schemas only
agreement, Yves will implement that
need to say in "For Existing DTD or schema" that this works only if you have the same semantics as ITS 1.0 / W3C Ruby spec
agreement, Yves will implement that
ISSUE-13 Best Practice 8: Provide a way to specify comments for localizers
Needs to be clearer: relation between "comments", "notes", "instructions"
Felix: prefer to say "notes" to be used in the title
Richard: "notes", "comments,"
"instructions" in blue text
... repeated that in the following text
Felix: +1
agrement
Note: The its:rules element can be created in a separate file, but it is more efficient to allow the authors to include the rules directly into their documents." needs to be justifyfied
Yves: I'll try to come up with a reason, if not, I delete it
"tell the translator how to translate part of the content" not really necessary
Richard gives Yves an example to incorporate
ISSUE-14 Best Practice 9: Provide a way to specify unique identifiers
<YvesS> - "Make sure to have an ID attribute available for the elements that contain translatable text." Propose to say : "Make sure that the elements with translatable content are associated with a unique identifier".
<YvesS> Similar reworindgs needed for paragraph 2 and 3.
agreement on all parts of ISSUE-14
ISSUE-15 Best Practice 10: Identify terminology-related element
This BP sometimes talkes about elements, sometimes about markup. This should be harmonized.
agreement
example 19: last rule should be <its:termRule selector="//dt[../dd]" term="yes" termInfoPointer="../dd"/>
first sentence of "Why do this" section needs rewrite - editorial
concerns about "Identified terms could be used for indexing" paragraph.
everybody fine to drop the paragraph
concern from Felix: Is this BP and the "Terminology" data category for providing information to human readers or non-human processing?
Felix: propose to have s.t. sayimg: an implementation has to have a means to differentiate terminology information for humas vs. for machine processing
Richard: propose s.t. like that as a note in the "How to do this" section
ISSUE-16 Best Practice 11: Provide a way to override terminology-related
no issue here
ISSUE-17 we don't mention is:span anywhere, we might need a new BP for that
Yves: I will start a new BP on this
ISSUE-18 Best Practice 12: Use multilingual documents with caution
need more clarity: why do you need to start with single language documents. The note after example 22 raises the question
Yves needs to make the blue text more clearer, possibly changes to other parts of BP 12 as well
Richard: and move the note to the
"How to do this" section
... and we will write a note to say: we are talking about
copies of the same text in different languages
on Example 20: needs to be made explicit why <text xml:lang="ja"></text> has no content
Jirka: remove the Japanese element
Felix: +1
ISSUE-19 Best Practice 13: Name elements and attributes with caution
comment on example 26: This is bad since the xml:id attributes are overloaded: they both identify and classify <str> elements. Proposal: use a type attribute instead of xml:id
objected
ISSUE-20 Best Practice 14: Provide an ITS rules for your DTD or schema
clarify that BP 14 relates to what you have implemented (no matter if done through ITS or not)
Yves will provide a clarification
"For example, DocBook has been used to document XSL." Propose to delete this sentence, agreed
"ITS rules files are a good choice for the following reasons:" needs rewording
skiped
example 27: delete tei namespace from example - done by Yves
ISSUE-21 Best Practice 15: Specify the language of the content
s.t. missing on paragraph 1 of "how to do this"
"on each element where the content of the language changes" added
example 29 : Example needs a reference to Best Practice 12: Use multilingual documents with caution
Yves: agree
example 29 again: The values for German and Japanese sound strange. Need to check these and others.
<scribe> ACTION: Felix to check translations for Japanese and German in example 29 [recorded in http://www.w3.org/2007/10/03-i18nits-minutes.html#action06]
<trackbot-ng> Created ACTION-29 - Check translations for Japanese and German in example 29 [on Felix Sasaki - due 2007-10-10].
BP should mention that you have to use span element sometimes
agreement
example: 30:: lanngrule should be <its:langRule selector="//lang[@code]" langPointer="@code" />
agreement
selecting proper formatting properties for data such as date, time, numbers, etc." Propose to drop the bullet point
agreement
reference links: put "Language tags in HTML and XML" first, BCP 47 after
agreement
ISSUE-22 Fix for pointer attributes
General fix for pointer attributes: XPath in selector attribute needs to check for match of relative XPath expression in pointer attribut
agreement
ISSUE-23 Encourage declaration of its:rules element or not?
Do we want to encourage people to declare its:rules specific to their needs? If no, this should be "the its:rules" element. If yes, it should be "its:rules" element, and we need to make clear that people possibly have to adapt its:rules.
Yves: people should keep everything, except if they have the functionality already (e.g. a translate attribute in their schema)
agreement we don't need to do anything
ISSUE-24 Best Practice 16: Specify text directionality if needed
suggest to link to one of the articles: http://www.w3.org/International/questions/qa-bidi-controls
agreed
address "why not use CSS"? and "why not using xml:lang to achieve the same result?"
xml: lang is addressed, Yves will rewrite this
on CSS:
Richard: you should not use just CSS, you need markup dedicated to BIDI-structure
<r12a-CZ> http://www.w3.org/International/questions/qa-bidi-css-markup
Richard: we need to say: don't
use language attributes, don't use CSS, and don't use CSS to
define the semantics
... use CSS to deifne expected behavior
... expected behavior is given by rules like CSS rule:
*[dir="ltr"] { unicode-bidi: embed; direction: ltr}
... [dir="ltr"] could also be a different selector, depending
on the markup in use
Yves: will make a rewording
Best Practice 17: Override translatability information if needed
note should go higher
not implemented, agreed
ISSUE-26 Best Practice 18: Best Practice 18: Assign unique identifiers to text items when possible
"Make sure to assign a unique identifier to any element where it can be set.": not sure if this makes sense e.g. might be too fine grained for inline-elements
Jirka: maybe "where i can be useful for localization"
agreed
<bbogacki> Hi Guys
<bbogacki> should I connect to the teleconf?
<YvesS> Hi Bartosz
<YvesS> Yes
"If possible, use globally unique and persistent values as identifiers": I'm confused: should just the values of the attribute be unique, or is it OK to use a different mechanism than ID type attributes? The note in BP 9 "Using identifiers that are globally unique (i.e. unique across any documents) and persistent (i.e. ones which do not change over time) often provides additional benefits."...
scribe: Suggested the latter
Proposal from RIihard "Use unique identifiers (or its equivalent in your DTD or schema) on each element that can be uniquely identified. "
+1
Richard: "or its equivalent in " : as provided by "
ISSUE-27 make clear: Who writes the ITS rules?
Yves: in BP 14 we may want to add
some information about that
... will add s.t. to BP 14 about that
ISSUE-28 have a general statement which says: this is the knowledge you need to understand these subparts of the document
Yves: could say in introduction that some BPs require some knowledge of XPath
agreed
ISSUE-29 Best Practice 19: Avoid CDATA sections when possible
CDATA should always be "CDATA sections", not just CDATA or "CDATA notation - agreed
need an example of xinclude or xlink
<scribe> ACTION: Jirka to l create an example with xinclude for BP 19 [recorded in http://www.w3.org/2007/10/03-i18nits-minutes.html#action07]
<trackbot-ng> Created ACTION-30 - L create an example with xinclude for BP 19 [on Jirka Kosek - due 2007-10-10].
the problem is valid also for translating documents, not just changing the encoding
Yves: will create some text about tthat
ISSUE-30 Best Practice 20: Provide comments for localizers
already decided, see BP 8
ISSUE-31 Best Practice 21: Ensure any inserted text is context-independent
value of conref on example41 looks strange - fixed
if DITA material is published, have a link to that? - yes,
example 39 and 40 are not illustrating the point correctly
<scribe> ACTION: Richard to provide correction for examples 39 and 40 [recorded in http://www.w3.org/2007/10/03-i18nits-minutes.html#action08]
<trackbot-ng> Sorry, amibiguous username (more than one match) - Richard
<trackbot-ng> Try using a different identifier, such as family name or username (eg. rishida, frichard)
<scribe> ACTION: rishida to provide correction for examples 39 and 40 [recorded in http://www.w3.org/2007/10/03-i18nits-minutes.html#action09]
<trackbot-ng> Created ACTION-31 - Provide correction for examples 39 and 40 [on Richard Ishida - due 2007-10-10].
Best Practice 22: Use entity references with caution
propose to drop this , agreement
ISSUE 33 Best Practice 23: Place sub-flow elements with caution
propose to drop this , agreement
ISSUE-34 Best Practice 24: Identify terms
"This is more efficient than adding markup in the body of the document." in example 44: , add "for each instance of the UI element"
agreement
"the translation project manager": no need to mention these
agreement
main reason for the section is that terms should be marked up, not the overriding case
Felix: examples are too complex
Yves: need to find a simple example with just markup for the term
agreement, and we need to keep the overriding example
ISSUE-35 Best Practice 25: Avoid storing markup as text
not clear what the problem is
Richard: propose "Use namespaces rather than escaping markup"
<Jirka> What about "Avoid storing markup in an escaped form"?
<bbogacki> Separate translatable content from control data
<r12a-CZ> bartosz you will need to accept me as a contact, i think
<r12a-CZ> bartosz you will need to accept me as a contact, i think
Yves: Avoid including markup in escaped form
agreement, including "Use namespaces rather than escaping markup" for blue text from Richard
ISSUE-36 Sec. 4.1.2 Dealing with namespaces
needs more examples
Jirka: could copy other examples or point to others
Yves: will create an example
ISSUE-37 Sec. 4.1.3 Create your XPath expressions with care
"The values of ITS pointer attributes are XPath relative location paths": propse to have a list of these attributes with links to their declaration
agreement
locNotePointer, locNoteRefPointer, termInfoPointer, termInfoRefPointer, rubyPointer, rtPointer, rpPointer, rbcPointer, rtcPointer, rbspanPointer, langPointer.
ISSUE-38 Sec. 4.2
These examples cannot be generalized. There are tons of other, schema language specific mechanisms for adding attributes. Proposal: change the title to "Example of adding an Attribute to an Existing DTD or Schema", and add "Note that these examples only show a few ways of adding attributes. There are many others, depending. on the schema language and e.g. the modularization, techniques used...
scribe: in the existing schema."
agreeemnt
propose to unify examples. E.g., each example currenlty defines a differenlty named element
agreement
Jirka will follow up
example 52 needs to be changed to have the union type, Jirka will provide a declaration
ISSUE-39 Sec. 5.1.2 Using XHTML Modularization 1.1 for the Definition of ITS
not sure if we should remove it. Let's keep it in here for now and tell XHTML2 people
First paragraph after blue text is often similar to the blue text. that's a general issue for many BPs, needs to be harmonized / reworked
<r12a-CZ> http://www.w3.org/TR/i18n-html-tech-lang/#ri20030112.213804197
this is ISSUE-40 Content of blue text
<r12a-CZ> http://www.w3.org/TR/i18n-html-tech-lang/#contents
Yves: three areas which say the
same thing: title, blue text, "how to do this"
... two solutions: have blue text as a reformulation of what we
say in "how to do this", or
... have blue text as very generic, without explicit attribute
naming etc.
... agree with reworking of blue text. Worried about title
changes
(discussion concerns ISSUE-40 and ISSUE-41)
for the title, we change it to "...ing" forrms, like "Dealing with ..."
ISSUE-42 Position of "For existing DTD and schema:" material and material about new schemas
Yves: we agree on having the two
kinds of material at the same level
... "how" to do this be replaced by s.t. like "creating the new
feature"
... and "handling legacy scenarios"
stop meeting for now, follow up tomorrow / tonight
we will not go through issues discussed at topic 1 - 15 of today
people have AIs to work on these