Re: i18n comments: (was: [widgets] Span example)
The spec itself looks fine. It seems that the schema at
http://dev.w3.org/2006/waf/widgets-schema/widgets.rnc
is not up to date yet. It still contains the *ITS* dir attribute, e.g. at
elem.author = element author {
attr.xmllang?,
attr.itsdir?,
attribute href { xsd:anyURI }?,
attribute email { xsd:string { pattern=@.+ } }?,
text?
}
I think you need to rename attr.itsdir to attr.dir , and change
attr.itsdir = attribute its:dir { ltr | rtl | lro | rlo }
to
attr.dir = attribute dir { ltr | rtl | lro | rlo }
Best,
Felix
2010/3/26 Richard Ishida ish...@w3.org
[Changing the subject to keep the review comment thread clean]
Personally, I think we're ok with the changes.
RI
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)
http://www.w3.org/International/
http://rishida.net/
-Original Message-
From: Arthur Barstow [mailto:art.bars...@nokia.com]
Sent: 19 March 2010 11:49
To: Richard Ishida; Addison Phillips; Felix Sasaki;
public-i18n-c...@w3.org
Cc: public-webapps; Marcos Caceres
Subject: Re: [widgets] Span example
Richard, Addison, Felix, All,
Based on my conversations with Marcos and reading this thread, it is
my understanding that you support:
a) the new span element and dir attribute model Marcos added to the
Widget PC spec [PC-ED] and consequently,
b) the removal of the ITS references that were in the December CR
[PC-CR].
Would you please confirm this or if my understanding is not correct,
please elaborate on any remaining issues?
Also, if you have any feedback on the 60 related test cases Marcos
created, please reply to the thread he used to announce those test
cases:
[widgets] dir and span tests
http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/
0845.html
-Thanks, Art Barstow
[PC-ED] http://dev.w3.org/2006/waf/widgets/
[PC-CR] http://www.w3.org/TR/2009/CR-widgets-20091201/
On Mar 16, 2010, at 3:15 PM, ext Marcos Caceres wrote:
Hi Richard,
Added the example at:
http://dev.w3.org/2006/waf/widgets/#span
Please see also the examples for the dir attribute:
http://dev.w3.org/2006/waf/widgets/#dir
Thanks again for all your time and help!
On Tue, Mar 16, 2010 at 7:58 PM, Richard Ishida ish...@w3.org wrote:
[This is a continuation of one part of the http://lists.w3.org/
Archives/Public/public-i18n-core/2010JanMar/0043.html thread.]
It addresses the comment:
[[ 7.16. The span Element http://dev.w3.org/2006/waf/widgets/
#the-span-element-and-its-attributes
[2] I think the example could be improved by having something
inside the span with punctuation (eg. exclamation mark) or such,
and maybe the description should be in English - otherwise you'd
probably want to put the dir on the widget tag and have English in
the span. Should I try to find another example ?
]] at http://www.w3.org/International/reviews/0907-widgets-pc/
Here's my proposed example (thanks to Aharon Lanin for helping
with the Hebrew). I made up something that might appear in a
Hebrew widget, rather than an English one, since it's a little
more realistic.
widget
xmlns=http://www.w3.org/ns/widgets;
xml:lang=he dir=rtl
name xml:lang=enGPS Weather!/name
description
יישומון ה-span dir=rtl xml:lang=enGPS Weather!/
span מאפשר לך לבדוק את מזג האוויר בכל
נקודת GPS ברחבי העולם.
/description
/widget
Here's a version ready to drop into HTML (I suggest you copy it as
a unit, to avoid problems with the bidirectional text.)
lt;widget
xmlns=quot;http://www.w3.org/ns/widgetsquot;
xml:lang=quot;hequot; dir=quot;rtlquot;gt;
lt;name xml:lang=quot;enquot;gt;GPS Weather!lt;/namegt;
lt;description
יישומון ה-lt;span dir=quot;rtlquot;
xml:lang=quot;enquot;gt;GPS Weather!lt;/spangt; מאפשר
לך לבדוק את מזג האוויר בכל נקודת GPS
ברחבי העולם.
lt;/descriptiongt;
lt;/widgetgt;
--
Marcos Caceres
http://datadriven.com.au
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.791 / Virus Database: 271.1.1/2755 - Release Date: 03/20/10
19:33:00
Re: [widgets] dir and span elements
Hi Marcos, 2010/3/10 Marcos Caceres marc...@opera.com Hi Addison, Richard, and i18 WG, [snip] Upon reflection on the discussion above, I think the dir attr must behave the same as xml:lang - meaning that the value of dir is applied to the element, all its attributes, and its child nodes. Correct. This is also how the element is defined in ITS, see the inheritance column at http://www.w3.org/TR/its/#datacategories-defaults-etc : Textual content of element, *including* attributes and child elements, the same as language information in the same table (a mediator for xml:lang). Best, Felix
Re: [widgets] Testing ITS support
Hello Marcos, in case you are also aiming at support for other ITS elements and attributes: you could adapt the following tests from the ITS test suite http://www.w3.org/International/its/tests/ which the ITS Working Group used for attributes at the its:span element. TRANSLALTE Local - In its:span Sourcehttp://www.w3.org/International/its/tests/inputdata/Translate3.xml Resulthttp://www.w3.org/International/its/tests/expected/Translate3-result.xml Resulthttp://www.w3.org/International/its/tests/test1/Translate3-result.xml Resulthttp://www.w3.org/International/its/tests/test2/Translate3-result.xml Resulthttp://www.w3.org/International/its/tests/test3/Translate3-result.xml LOCALIZATION NOTE Local - In its:span with mixed notes Sourcehttp://www.w3.org/International/its/tests/inputdata/LocNote4.xml Resulthttp://www.w3.org/International/its/tests/expected/LocNote4-result.xml Result http://www.w3.org/International/its/tests/test1/LocNote4-result.xml Result http://www.w3.org/International/its/tests/test2/LocNote4-result.xml Result http://www.w3.org/International/its/tests/test3/LocNote4-result.xml TERMINOLOGY Local - In its:span Sourcehttp://www.w3.org/International/its/tests/inputdata/Terminology4.xml Resulthttp://www.w3.org/International/its/tests/expected/Terminology4-result.xml Resulthttp://www.w3.org/International/its/tests/test1/Terminology4-result.xml Resulthttp://www.w3.org/International/its/tests/test2/Terminology4-result.xml Resulthttp://www.w3.org/International/its/tests/test3/Terminology4-result.xml As you can see from the results, the implementation just has to be able to make the ITS information available for further processing. So if you have build three similar tests for these ITS data categories and one for directionality (see Richards pointer), you are done IMO. Best, Felix 2009/11/27 Marcos Caceres marc...@opera.com Dear i18n WG, During the call to transition the Widgets Packaging and Configuration specification (PC) [1] to CR, the Director requested that aside from the MUST assertions the Web Apps WG test the optional aspects of the specification in our test-suite [2]. As you are aware, to facilitate the localization of text nodes within XML elements in a configuration document, a user agent may support the Internationalization Tag Set's its:span element and the its:dir attribute (It is optional for a user agent to support other ITS elements and attributes). In order to test ITS support, the WebApps WG would appreciate some guidance with designing a handful of test cases that the i18n WG would consider suitable to provide interoperability across implementations. The its:span element can be used as a child element of the following elements of the configuration document. In addition, the its:dir attribute can be used in the following elements of the configuration document: * name * description * author * license Any guidance or help the i18n WG can provide us with designing test would be greatly appreciated. We are intending to transition this document to Proposed Recommendation at the end of January, but we would like to have the i18n tests done ASAP. I'm happy to work on the tests, so long as someone from i18n can guide me :) Hope the i18n WG can again help us out! Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets/ [2] http://dev.w3.org/2006/waf/widgets/test-suite/
Re: Is there proposal of accessing metadata of media files?
Hello Dzung, sorry for jumping in, but from http://dev.w3.org/cvsweb/~checkout~/2009/dap/api-reqs/Overview-FPWGN.html?rev=1.6content-type=text/html;%20charset=utf-8#gallery Exposing metadata is tricky, often giving a choice between creating an endless ontology or building an open-ended system that guarantees no interoperability. I am not sure what you are looking for: - an ontology defining mappings between existing metadata (being defined by media annotations working group (MAWG)) - new metadata properties defined as an ontology (not defined by MAWG) - an API which reflects the mapping of existing properties in the ontology to access methods for metadata (provided by MAWG) - an API for low-level reading mechanisms (not provided by MAWG - e.g. for XML-based formats provided by an XML-parser) Best, Felix 2009/10/14 Tran, Dzung D dzung.d.t...@intel.com I haven't heard any comments from the Media Annotations WG. The Gallery API status is gated from any further progress if it is necessary due to the existence of Media Resource API. Dzung Tran Intel Corporation -Original Message- From: public-device-apis-requ...@w3.org [mailto: public-device-apis-requ...@w3.org] On Behalf Of Robin Berjon Sent: Wednesday, October 07, 2009 03:40 PM To: Arthur Barstow Cc: Soohong Daniel Park; ext Shumpei Shiraishi; public-webapps WG; public-media-annotat...@w3.org; public-device-a...@w3.org Subject: Re: Is there proposal of accessing metadata of media files? Hi, On Oct 7, 2009, at 15:39 , Arthur Barstow wrote: Soohong, Media Annotations WG - would you please provide a short update/status and plans regarding your Media API spec? Also, is this the most recent API document: http://dev.w3.org/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1.0.html Could you also copy DAP (cc'ed) please? We have an API in our list (Gallery) that could probably be expressed simply with File System plus some metadata. We certainly wouldn't mind being able to declare an easy victory there. [For those who are missing the context, it's at http://www.w3.org/mid/de062981-b996-4da0-a2de-e8fce3475...@nokia.com ] -- Robin Berjon - http://berjon.com/
Re: [widgets] i18n proposals document
Hello Marcos, I have no input on your scenarios, but as Mark pointed out, they are not i18n in the usual sense, rather localization. I am putting the ITS IG into the loop, maybe they have comments on what scenario is appropriate. Your usage of bcp 47 is of course appropriate for i18n, and I'm sure Mark and Addison will have more comments on these. Felix 2009/4/16 Mark Davis mark.da...@icu-project.org I just glanced at this, but the first line is wrong: Internationalization, or i18n, is the automated process employed by a user agent to select localized content from a widget package that matches the language preferences of an end-user. If you want a term for the latter phrase, fine. But that isn't the meaning of internationalization, which is a development process (enabling a program to be easily localized, without code changes). internationalization is not a user runtime selection process. Mark On Thu, Apr 16, 2009 at 09:41, Marcos Caceres marc...@opera.com wrote: Hi i18n WG Members, As Web Apps has been struggling a bit to come to consensus on a coherent i18n model for widgets, we've prepared a document that attempts to map out a complete internationalization model for the Widgets 1.0: Packaging and Configuration specification: http://dev.w3.org/2006/waf/widgets/i18n.html The purpose of the document is to tease out the complexities of an i18n model for widgets and to make a number of proposals that together form a complete i18n solution. The Web Apps WG would like to solicit some expertise from the i18n Working Group in getting this right. The document is a work in progress an should be considered an early draft (it basically just contains a bunch of strawperson proposals). I will continue attempting to improve document over the next few days, but please feel free to start sending feedback if you have any. Our intention is to decide what the best proposals are and integrate them into the Widgets 1.0 Packaging spec. I18n is basically the most significant issues blocking our spec from going to Second Last Call. We would really appreciate any thoughts or comments the i18n community might have (by the 23 of April if at all possible). Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] i18n span element VS unicode RLM/LRM
Hi Marcos,
thank you very much for your response. I am happy with your resolution.
One comment below
Marcos Caceres さんは書きました:
Hi Felix (and i18n Core),
During our last WAF teleconf, WebApps decided to adopt your
suggestions (below). I've been attempting to integrate your
suggestions into the Widget Packaging spec [1]. Below I summarize what
draft text I have added thus far. I would really appreciate any
feedback if you think I've gone about specifying what you intended
correctly.
On Thu, Sep 11, 2008 at 1:32 AM, Felix Sasaki [EMAIL PROTECTED] wrote:
Marcos Caceres wrote:
Hi, i18n-WG.
In recent feedback we received from Addison Phillips regarding the
Widgets 1.0: Packaging specification, he suggested that WebApps should
add a span-like element to our Widget Configuration Document format
(so to allow bidi text to be declared).
I think such an element would only be necessary within these elements: name,
description, author, license. It seems that only these elements may contain
human readable text.
Agreed. More on this below.
snip
I personally would recommend you to use the its:span element in the ITS
namespace. The element is defined at
http://www.w3.org/TR/2007/REC-its-20070403/#span
This element gives you the dir attribute and various other attributes
which are useful for esp. Widgets localization. See
http://www.w3.org/TR/2007/REC-its-20070403/#att.local.no-ns.attributes
See also the related Best Practice to define such an element for XML
vocabularies at
http://www.w3.org/TR/2008/NOTE-xml-i18n-bp-20080213/#DevSpan
To keep simplicity for Widgets 1.0, you could say in your conformance
description that a Widgets processor has various options to deal with the
its:span element (or more in general: the ITS namespace) and its
attributes: ignore them or process them.
Ok, in the Widget User Agent conformance section I've added the
following text for your consideration:
A widget user agent MAY support the Internationalized Tag Set's
its:span element and the its:dir attribute [ITS]. Support of any
other ITS elements and attributes is NOT REQUIRED. Although this
specification specifies the elements of the configuration document in
which its:span and its:dir can be used (below), it does not define
how they are to be interpreted and processed by a widget user agent.
If a widget user agent implements its:span and its:dir, then they
MUST do so in conformance to the processing rules defined by the ITS
specification.
Then I've added the following subsection to the Configuration Document
section...
== Indicating text directionality and its:span ==
Although it is optional for a widget user agent to implement [ITS],
authors are may use the its:span element to indicate the
directionality of arbitrary content. Directionality is indicated by
using the its:dir attribute in conjunction with the its:span
element. The its:dir accepts one of the following values, as defined
in [ITS]:
dir=ltr - left to right text
dir=rtl - right to left text
dir=lro - left-to-right override
dir=rlo - right-to-left override
For example,
widget
xmlns=http://www.w3.org/ns/widgets;
xmlns:its=http://www.w3.org/2005/11/its;
nameYay for the its:span dir=rtlمتعة الأسماك!/its:span
Widget/name
/widget
The its:span element can be only be used as a child of the following
elements of the configuration document:
* name
* description
* author
* license
If you do not want to add markup from a specific namespace, you could or
should IMO add extensibility points for people who need such markup. That
is, change in the schema something like
description = element description {
xmllang.att?,
text
}
to
description = element description {
xmllang.att?,
any
}
and define any and a pattern anyElement as
any= (attribute * { text }
| text
| anyElement)*
anyElement = element * { any }
after looking at this again I am thinking you could also say:
any= (attribute * - w:* { text }
| text
| anyElement)*
anyElement = element * - w:* { any }
-w:* (assuming that the w prefix is bound to the widgets namespace)
means that you exclude native widgets markup from the any defintions.
That is just a suggestion, no need to handle this as a formal comments.
Regards, Felix.
Again the conformance for such markup can say: ignore it (it meaning:
markup from other namespaces) or process it. I think you are basically
saying that already at http://www.w3.org/TR/widgets/#extensions
Agreed. Our schema will be updated to include the above.
Thank you again for your help! And looking forward to hearing any
feedback you might have,
Marcos
Re: [widgets] i18n span element VS unicode RLM/LRM
Hello Marcos,
many people from the i18n core WG are away this week, so there might be
more replies later. This is a personal reply.
Marcos Caceres wrote:
Hi, i18n-WG.
In recent feedback we received from Addison Phillips regarding the
Widgets 1.0: Packaging specification, he suggested that WebApps should
add a span-like element to our Widget Configuration Document format
(so to allow bidi text to be declared).
I think such an element would only be necessary within these elements:
name, description, author, license. It seems that only these elements
may contain human readable text.
At our last F2F, WebApps discussed the proposition and we were left
wondering if we can use unicode's RLM/LRM characters instead of a
span-like element? Can i18n please advise us on this?
See
http://www.w3.org/TR/2008/NOTE-xml-i18n-bp-20080213/#DevDir
and
http://www.w3.org/TR/2007/NOTE-unicode-xml-20070516/#Bidi
I will not repeat the arguments here, but the conclusion is that indeed
an attribute for directionality information would be better than relying
on Unicode control characters.
Not having the
span-like element significantly simplifies our processing model. We
don't want to sacrifice i18n for the sake of simplicity, so we really
need your guidance again on how to move forward.
I personally would recommend you to use the its:span element in the
ITS namespace. The element is defined at
http://www.w3.org/TR/2007/REC-its-20070403/#span
This element gives you the dir attribute and various other attributes
which are useful for esp. Widgets localization. See
http://www.w3.org/TR/2007/REC-its-20070403/#att.local.no-ns.attributes
See also the related Best Practice to define such an element for XML
vocabularies at
http://www.w3.org/TR/2008/NOTE-xml-i18n-bp-20080213/#DevSpan
To keep simplicity for Widgets 1.0, you could say in your conformance
description that a Widgets processor has various options to deal with
the its:span element (or more in general: the ITS namespace) and its
attributes: ignore them or process them.
If you do not want to add markup from a specific namespace, you could or
should IMO add extensibility points for people who need such markup.
That is, change in the schema something like
description = element description {
xmllang.att?,
text
}
to
description = element description {
xmllang.att?,
any
}
and define any and a pattern anyElement as
any= (attribute * { text }
| text
| anyElement)*
anyElement = element * { any }
Again the conformance for such markup can say: ignore it (it meaning:
markup from other namespaces) or process it. I think you are basically
saying that already at http://www.w3.org/TR/widgets/#extensions
Regards, Felix.
Having read Internationalization Best Practices: Handling
Right-to-left Scripts in XHTML and HTML Content, we are aware that
there are problems with text editors ATM, but we are hoping the tools
will improve as Unicode support becomes more common place (or is that
wishful thinking?).
Kind regards,
Marcos
