Re: [Spec Reviews] Internationalization Best Practices for Spec Developers
hi Art, On 20/10/2015 11:44, Arthur Barstow wrote: I presume this document (or a document like this) would be used (useful) when a spec is getting "wide review" from an internationalization perspective. i'm hoping it will eventually be useful even before then, since people working on a spec can run through the checklist to identify topics that need consideration. One of the aims in creating this was to get some of the knowledge in our i18n WG heads out there so that groups could self-educate. that said, the do's and don'ts are still at an early stage of development, so there may be a need for discussions between groups before things are settled, and we intend to add more material as we go forward too. if anyone reading this uses the checklist and related information, we'd be grateful to hear from them where there are issues and how we could improve things. cheers, ri
Re: Copying multi-range selection
On 15/08/2015 22:24, Phillips, Addison wrote: This appears to make visual selection appealing--although it doesn't, for the reasons mentioned elsewhere, lead to sensible text operations unless the selected run happens to be all in a single direction. and if the text runs all in a single direction, there's no difference between logical and visual selection anyway, right?. ri
Re: Copying multi-range selection
On 15/08/2015 13:38, Anne van Kesteren wrote: On Sat, Aug 15, 2015 at 10:23 AM, Richard Ishida wrote: what's the use case driving this, and where are the requirements coming from? i ask because i'm inclined to think that the circumstances in which this would a produce useful results, given the way it carves up the actual content, are quite, perhaps extremely, limited. Well, the web platform "supports" editing, text selection, and drag-and-drop/copy-and-paste, etc. through various APIs. The question is how those should work with RTL content. my question was specifically, why do it in a non-standard way for bidi text? (typical scenario is split visual but one range internally) ri
Re: Copying multi-range selection
On 15/08/2015 06:19, Anne van Kesteren wrote: On Sat, Aug 15, 2015 at 12:10 AM, Ryosuke Niwa wrote: We've been recently exploring ways to select bidirectional text and content that uses new CSS layout modes such as flex box in visually contagious manner. Because visually contagious range of content may not be contagious in DOM order, doing so involves creating a disjoint multi-range selection. There has been quite a bit of discussion about how we can better expose that to the Web since the current model of exposing a list of Range objects doesn't seem to be working well. However, another important question I have is how copying such a selected content work? Do we just stitch together disjoint content? But that may result in the content being pasted in completely different order. I copied www-international. Somewhat curious if this problem has been studied before. It does seem like you would have to add/remove formatting code points as the context where you paste may be different from the context where you copied from. what's the use case driving this, and where are the requirements coming from? i ask because i'm inclined to think that the circumstances in which this would a produce useful results, given the way it carves up the actual content, are quite, perhaps extremely, limited. ri
Re: I18N comments on "Manifest for Web applications"
is it possible to send mail to www-internatio...@w3.org each time someone adds somethign to the github issue? (this is the list where we track and discuss issues). if so, i see no real difference between using github or bugzilla – our process is designed to cope with both bugzilla and email based comments (though it would normally be better to start with the right one rather than switch part way, so changing the SOD would indeed help). we should also ensure, however, that the titles of the issues and any associated notification mails always contain the i18n-issue-xxx string that will allow us and tracker to locate information for a given thread. ri On 20/03/2015 16:40, Christiansen, Kenneth R wrote: Marcos, Anssi, what do you think? I would prefer the comments on GitHub as it seems to be a great place for interacting with the web community, judging from our success so far. Kenneth -Original Message- From: Phillips, Addison [mailto:addi...@lab126.com] Sent: Friday, March 20, 2015 4:43 PM To: Christiansen, Kenneth R; public-webapps@w3.org Cc: public-i18n-c...@w3.org Subject: RE: I18N comments on "Manifest for Web applications" Hi Kenneth, Thanks for the reply. I know you're using GitHub. However, whenever I'm filing/forwarding comments on a document on behalf of the Working Group, I always look at the SOTD in the document in question to see what instructions the receiving WG has. In this case, you have a fairly generic SOTD, which says in part: -- This document was published by the Web Applications (WebApps) Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-webapps@w3.org (subscribe, archives). All comments are welcome. -- If you prefer to have comments filed to GitHub, perhaps modify your instructions? Thanks! Addison Addison Phillips Globalization Architect (Amazon Lab126) Chair (W3C I18N WG) Internationalization is not a feature. It is an architecture. -Original Message- From: Christiansen, Kenneth R [mailto:kenneth.r.christian...@intel.com] Sent: Friday, March 20, 2015 1:15 AM To: Phillips, Addison; public-webapps@w3.org Cc: public-i18n-c...@w3.org Subject: RE: I18N comments on "Manifest for Web applications" Hi there, The spec authors use GitHub for issue tracking. I duplicated your issues there: https://github.com/w3c/manifest/issues Thanks for looking into internationalization issues with the current spec. Cheers, Kenneth -Original Message- From: Phillips, Addison [mailto:addi...@lab126.com] Sent: Thursday, March 19, 2015 6:20 PM To: public-webapps@w3.org Cc: public-i18n-c...@w3.org Subject: I18N comments on "Manifest for Web applications" Hello Webapps, As previously mentioned, I am about to send you comments from the Internationalization Working Group on your document (whose current iteration lives at [1]). Because we use Tracker for our comments, I will be sending each comment under separate cover. The I18N WG is always happy to discuss our comments or ways to address same. Please let me know if you prefer to receive comments in a different format (such as Bugzilla) or if you need additional information. If you want to see a summary of our comments, you can find them tracked at [2] Regards (for I18N) Addison [1] http://www.w3.org/TR/appmanifest/ [2] http://www.w3.org/International/track/products/74 Addison Phillips Globalization Architect (Amazon Lab126) Chair (W3C I18N WG) Internationalization is not a feature. It is an architecture.
Re: Overview of W3C technologies for mobile Web applications
On 08/03/2011 15:08, Somnath Chandra wrote: We have already started working on Mobile Rendering Engine and Fonts development which would enable seamless display across platforms and devices. That's interesting. Did you know about work currently under way involving Harfbuz to provide a small, universal rendering engine that can be used on mobile devices and other kinds of OS to do opentype rendering? [1] Are you working on the same thing? I'd hate to think that you are reinventing the wheel such that different systems are needed for different fonts... RI [1] http://behdad.org/text/ -- Richard Ishida Internationalization Activity Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/
RE: [widgets PC] i18n comment 20 : Misuse of xml:lang for localization flag
[Forwarding the relevant part of Addison's email as part of the original thread] > To: art.bars...@nokia.com; ext Richard Ishida > Cc: 'Felix Sasaki'; 'Marcos Caceres'; 'Robin Berjon'; 'Steven Pemberton'; > 'Doug > Schepers'; 'Charles McCathieNevile'; 'www-archive' > Subject: RE: [widgets] Re: i18n comments: > > Dear Art, et al, > ... > 4. I personally disagree with Richard's comment #20 [2]. The empty language > tag is related to locale fallback in that it represents the root of the locale > hierarchy, a position you could fill with "i-default", save that that value > doesn't > play nicely with BCP 47 fallback. The xml:lang="" is the default content. I > don't > agree that this is "unlocalized", which is your description. See my comment #2 > above. ... > Addison > ... > Addison Phillips > Globalization Architect (Lab126) > Chair (W3C I18N, IETF IRI WGs) > > Internationalization is not a feature. > It is an architecture. > > -Original Message- > From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core- > requ...@w3.org] On Behalf Of Richard Ishida > Sent: 20 May 2010 18:14 > To: public-i18n-c...@w3.org; public-webapps@w3.org > Subject: [widgets PC] i18n comment 20 : Misuse of xml:lang for localization > flag > > Comment from the i18n review of: > http://dev.w3.org/2006/waf/widgets/ > > Comment 20 > At http://www.w3.org/International/reviews/0907-widgets-pc/ > Editorial/substantive: S > Tracked by: RI > > Location in reviewed document: > 7.16.1 [http://dev.w3.org/2006/waf/widgets/#example-of-usage9] > > Comment: > Note: I am marking this as closed straight away, since I believe it was not > spotted early enough to be corrected. I am recording it here, however, in > case it is useful for a future discussion. > > > xml:lang should really only be used to indicate the language of content in an > element. If you need to indicate something else, such as the locale for that > content for localization purposes, you should use a different attribute. See > href="http://www.w3.org/International/questions/qa-when-xmllang";>xml:lang > in XML document schemas. Here not only is xml:lang used incorrectly > for that reason, but xml:lang="" is defined to mean that this is the default > locale, whereas the XML spec says that that should mean that the language > of the content of that element is undetermined (see Tagging text with no > language [http://www.w3.org/International/questions/qa-no-language]). > > > It would have been better to use an attribute such as locale='en', > locale='fr', > or locale=''. This would be used alongside xml:lang. The former would > indicate how to process the document, the latter would be useful for things > like spell-checking, voice browsers, etc that need to understand the language > of the text they are processing. > > > This would simplify the code in the example in section 7.16.1. Instead of: > > > GPS > Weather! > > > you could simply use > > > GPS Weather! > > > > > > Richard Ishida > Internationalization Lead > W3C (World Wide Web Consortium) > > http://www.w3.org/International/ > http://rishida.net/
[widgets PC] i18n comment 21: Language tag case
[resent with corrected subject line] Comment from the i18n review of: http://dev.w3.org/2006/waf/widgets/ Comment 21 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: AP Location in reviewed document: General Comment: Language tags are presented as lowercase. While case has no meaning in language tags, they are typically canonicalized (and are recommended to use) the case conventions in BCP 47. See http://tools.ietf.org/html/bcp47#section-2.1.1 Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/
[widgets PC] i18n comment 23: i18n string
Comment from the i18n review of: http://dev.w3.org/2006/waf/widgets/ Comment 23 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: AP Location in reviewed document: 9.1 http://www.w3.org/TR/2009/WD-widgets-20090528/#processing-rules Comment: There is a term "i18n string". We typically do not like the term "i18n" to be used for anything (my car's license/number plate and my .sig are exceptions to this rule ;-)), and, in this case, it doesn't convey any meaning. I would prefer the term "localizable string", "localizable", or "language string". Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/
[widgets PC] i18n comment 22: Default content
Comment from the i18n review of: http://dev.w3.org/2006/waf/widgets/ Comment 22 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: AP Location in reviewed document: 8.4 http://www.w3.org/TR/2009/WD-widgets-20090528/#other-attributes Comment: There is an example of the empty language tag with the comment "The user agents will treat this as unlocalized content." This should be "user agent" singular. More importantly, there should be a distinction between "unlocalized" and "non-linguistic" or "undetermined" or at least "default content" (which is what you mean). Note that the tag "und" represents text whose language cannot be determined. I would suggest "default content" here (and elsewhere). Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/
[widgets PC] i18n comment 21: i18n string
Comment from the i18n review of: http://dev.w3.org/2006/waf/widgets/ Comment 21 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: AP Location in reviewed document: General Comment: Language tags are presented as lowercase. While case has no meaning in language tags, they are typically canonicalized (and are recommended to use) the case conventions in BCP 47. See http://tools.ietf.org/html/bcp47#section-2.1.1 Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/
[widgets PC] i18n comment 15 : Persian dir examples
*Further comments* related to the i18n review of: http://dev.w3.org/2006/waf/widgets/ Comment 15 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: RI Location in reviewed document: 7.5.3. Examples of Usage [http://dev.w3.org/2006/waf/widgets/#examples-of-usage] Comment: The first example displays incorrectly (eg. the angle bracket points the wrong way and is in the wrong place). Replace the appropriate bit of code with the following and this should look ok: <name short="آب و هوا"> آب و هوا برنامه</name> The third example seems to have rather strange ordering in the Persian text and English, and the English word seems like an odd one to have in English. How about the following? <widget xmlns="http://www.w3.org/ns/widgets">; <name short="Weather"> Weather! a totally awesome application! </name> <name short="آب و هوا" xml:lang="fa" dir="rtl"> <span dir="ltr" xml:lang="en">Weather!</span> برنامه واقعا بزرگ </name> </widget> Hope that helps, RI Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/
[widgets PC] i18n comment 20 : Misuse of xml:lang for localization flag
Comment from the i18n review of: http://dev.w3.org/2006/waf/widgets/ Comment 20 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: S Tracked by: RI Location in reviewed document: 7.16.1 [http://dev.w3.org/2006/waf/widgets/#example-of-usage9] Comment: Note: I am marking this as closed straight away, since I believe it was not spotted early enough to be corrected. I am recording it here, however, in case it is useful for a future discussion. xml:lang should really only be used to indicate the language of content in an element. If you need to indicate something else, such as the locale for that content for localization purposes, you should use a different attribute. See http://www.w3.org/International/questions/qa-when-xmllang";>xml:lang in XML document schemas. Here not only is xml:lang used incorrectly for that reason, but xml:lang="" is defined to mean that this is the default locale, whereas the XML spec says that that should mean that the language of the content of that element is undetermined (see Tagging text with no language [http://www.w3.org/International/questions/qa-no-language]). It would have been better to use an attribute such as locale='en', locale='fr', or locale=''. This would be used alongside xml:lang. The former would indicate how to process the document, the latter would be useful for things like spell-checking, voice browsers, etc that need to understand the language of the text they are processing. This would simplify the code in the example in section 7.16.1. Instead of: GPS Weather! you could simply use GPS Weather! Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/
[widgets PC] i18n comment 19 : Corrupted Chinese text
Comment from the i18n review of: http://dev.w3.org/2006/waf/widgets/ Comment 19 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: RI Location in reviewed document: 7.12.4 [http://dev.w3.org/2006/waf/widgets/#example-of-usage5] Comment: The Chinese characters in ? have become corrupted. Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/
[widgets PC] i18n comment 18 : Empty dir value
Comment from the i18n review of: http://dev.w3.org/2006/waf/widgets/ Comment 18 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: RI Location in reviewed document: 7.5.3 [http://dev.w3.org/2006/waf/widgets/#examples-of-usage] Comment: The last example shows an empty value for the dir attribute which is not specified elsewhere. I believe this example is a hark-back to an earlier draft that wasn't removed when we decided to remove dir="". ==== Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/
[widgets PC] i18n comment 17 : What ITS did
Comment from the i18n review of: http://dev.w3.org/2006/waf/widgets/ Comment 17 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: RI Location in reviewed document: Changes since last pubn [http://dev.w3.org/2006/waf/widgets/] Comment: I propose: "which is what ITS did" => "which is how ITS tags were formerly specified here" The ITS specification doesn't require use of a namespace, and it would be good to change this wording so that that idea is not incorrectly reinforced. Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/
[widgets] Korean text corrupted
8.5.2 http://dev.w3.org/2006/waf/widgets/#complex-example The characters in ??? ??? have become corrupted. Editorial Owner RI Not WG approved Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/
i18n comments: (was: [widgets] Span example)
[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 element and dir attribute model Marcos added to the > Widget P&C spec [P&C-ED] and consequently, > > b) the removal of the ITS references that were in the December CR > [P&C-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 > > [P&C-ED] http://dev.w3.org/2006/waf/widgets/ > [P&C-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 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. > >> > >> >> xmlns="http://www.w3.org/ns/widgets"; > >> xml:lang="he" dir="rtl"> > >> GPS Weather! > >> >> יישומון ה-GPS Weather! >> span> מאפשר לך לבדוק את מזג האוויר בכל > >> נקודת GPS ברחבי העולם. > >> > >> > >> > >> Here's a version ready to drop into HTML (I suggest you copy it as > >> a unit, to avoid problems with the bidirectional text.) > >> > >> <widget > >> xmlns="http://www.w3.org/ns/widgets"; > >> xml:lang="he" dir="rtl"> > >> <name xml:lang="en">GPS Weather!</name> > >> <description > >> יישומון ה-<span dir="rtl" > >> xml:lang="en">GPS Weather!</span> מאפשר > >> לך לבדוק את מזג האוויר בכל נקודת GPS > >> ברחבי העולם. > >> </description> > >> </widget> > >> > > > > > > > > -- > > 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] Span example
The example looks rather baroque, but I think it does illustrate a number of points. (I think that in real life it may be simpler to just use xml:lang="he" and dir="rtl" on the description tag in a localized config file like this. The example does currently illustrate inheritance though. It also shows how to markup up the language while still marking default text for localization failures. I hadn't realised that that was how you indicated the default for localization. FWIW I'd have preferred a special attribute for that, rather than overloading the xml:lang attribute, but I guess it's too late to change that now. An attribute like localizationdefault="yes" would reduce the need for the extra spans. You need a 'using' between 'world' and 'GPS' at the end of the English description. Cheers, RI Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/ > -Original Message- > From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On > Behalf Of Marcos Caceres > Sent: 17 March 2010 16:25 > To: Richard Ishida > Cc: public-webapps; public-i18n-c...@w3.org > Subject: Re: [widgets] Span example > > Hi Richard, > > On Tue, Mar 16, 2010 at 8:20 PM, Richard Ishida wrote: > > Argh. Sorry Marcos. The dir="ltr" > > > > I've made the following modifications to the example (to make it > compatible with our "element-based localization" model): > > [[ > ==Example of Usage== > > This section is informative. > > This example shows span elements being used to indicate directionality > of text as well as language information. Note that the name element's > xml:lang attribute is set to an empty string to allow it to be used as > unlocalized content in the process of element-based localization: > > > xmlns="http://www.w3.org/ns/widgets"; > xml:lang="he" dir="rtl"> > GPS > Weather! > > יישומון ה-GPS Weather! מאפשר לך > לבדוק את מזג האוויר בכל נקודת GPS ברחבי העולם. > > > >The GPS Weather! widget lets you check the > weather at any point around the world GPS. > > > > ]] > > > > > -- > 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/2751 - Release Date: 03/16/10 > 19:33:00
RE: [widgets] Span example
Argh. Sorry Marcos. The http://www.w3.org/International/ http://rishida.net/ > -Original Message- > From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On > Behalf Of Marcos Caceres > Sent: 16 March 2010 19:15 > To: Richard Ishida > Cc: public-webapps; public-i18n-c...@w3.org > Subject: Re: [widgets] Span example > > 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 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. > > > > > xmlns="http://www.w3.org/ns/widgets"; > > xml:lang="he" dir="rtl"> > > GPS Weather! > > > יישומון ה-GPS Weather! מאפשר לך > לבדוק את מזג האוויר בכל נקודת GPS ברחבי העולם. > > > > > > > > Here's a version ready to drop into HTML (I suggest you copy it as a unit, > to avoid problems with the bidirectional text.) > > > > <widget > > xmlns="http://www.w3.org/ns/widgets"; > > xml:lang="he" dir="rtl"> > > <name xml:lang="en">GPS Weather!</name> > > <description > > יישומון ה-<span dir="rtl" xml:lang="en">GPS > Weather!</span> מאפשר לך לבדוק את מזג האוויר בכל נקודת GPS ברחבי העולם. > > </description> > > </widget> > > > > > > -- > Marcos Caceres > http://datadriven.com.au > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.733 / Virus Database: 271.1.1/2745 - Release Date: 03/15/10 > 19:33:00
[widgets] Span example
[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. http://www.w3.org/ns/widgets"; xml:lang="he" dir="rtl"> GPS Weather! GPS Weather! מאפשר לך לבדוק את מזג האוויר בכל נקודת GPS ברחבי העולם. Here's a version ready to drop into HTML (I suggest you copy it as a unit, to avoid problems with the bidirectional text.) <widget xmlns="http://www.w3.org/ns/widgets"; xml:lang="he" dir="rtl"> <name xml:lang="en">GPS Weather!</name> <description יישומון ה-<span dir="rtl" xml:lang="en">GPS Weather!</span> מאפשר לך לבדוק את מזג האוויר בכל נקודת GPS ברחבי העולם. </description> </widget> Cheers, RI PS: This email has been sent as UTF-8. Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/
RE: [widgets] dir and span elements
I agree with Felix. Note also for example that the HTML 4.01 spec also says "This attribute specifies the base direction of directionally neutral text ... in an element's content *and attribute values*. " (my emphasis). There are, of course, some problems with applying directionality to attributes where their base direction is different than that of the element content or they contain text which needs to have embeddings applied to just a part of the text. These are some of the reasons that we and the ITS spec always advise against using user readable text in attributes - use elements for that stuff. RI ==== Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/ From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core-requ...@w3.org] On Behalf Of Felix Sasaki Sent: 10 March 2010 16:15 To: marc...@opera.com Cc: Phillips, Addison; Scott Wilson; public-webapps; public-i18n-c...@w3.org Subject: Re: [widgets] dir and span elements Hi Marcos, 2010/3/10 Marcos Caceres 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2732 - Release Date: 03/09/10 19:33:00
RE: [widgets] dir and span elements
Hi Marcos, Thanks for your quick work on this. I have a few comments. Hope they are helpful... [1] 7.16. The span Element http://dev.w3.org/2006/waf/widgets/#the-span-element There may be cases where span is also used to support xml:lang (not just dir). [2] same section 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 ? [3] same section "it allows authors to override the Unicode bidirectional algorithm by explicitly specifying a direction override, as specified in [BIDI]." There is no link on [BIDI], and there is no [BIDI] reference at the bottom of the page. [4] same text "it allows authors to override the Unicode bidirectional algorithm by explicitly specifying a direction override, as specified in [BIDI]." => "it allows authors to set the base direction for the Unicode bidirectional algorithm, as specified in [BIDI]." I propose this change because the dir attribute as you define it doesn't have the rlo and lro values that would mean 'override', it has only ltr and rtl, which define the base direction. I don't know if the 'as specified in...' bit is still relevant, since I don't know what that refers to. [5] dir attribute http://dev.w3.org/2006/waf/widgets/#global-attributes Any reason that you don't specify rlo and lro values recommend in the ITS spec? (They aren't use much, but I was wondering whether there was a particular reason that they aren't included.) [6] same section "An empty value of dir is used on an element B to override a specification of dir on an enclosing element A, without specifying another direction. Within B, it is considered that there is no directional information available, just as if dir had not been specified on B or any of its ancestors (see fourth example below)." We discussed this during the i18n telecon. We think having an empty value is a little odd, given that the direction has to be either ltr or rtl. (For instance, it has no real effect or meaning in the final example below this text that we can detect.) We also think that is may cause some unintended problems for embedded text by creating inappropriate embeddings. We suspect that what you really need is something that we are about to propose for HTML5 (in a working draft that should hopefully be published as FPWD today), ie. a bdi attribute (bidi isolate). It will be a little while before that is a stable document, however. In the meantime, our suggestion is that you drop the empty value for dir, and revisit this in a later version of the spec. [7] same section, examples The first example looks a little out of kilter wrt markup. (if you need help to sort it out just shout) Who provided the Persian translations? (I'd like to suggest some alternative examples, but I can't translate into Persian.) I hope those comments are helpful. RI Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/ > -Original Message- > From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core- > requ...@w3.org] On Behalf Of Marcos Caceres > Sent: 26 February 2010 17:45 > To: public-webapps > Cc: public-i18n-c...@w3.org > Subject: [widgets] dir and span elements > > Hi i18n WG, > I've added the dir attribute and span elements to the Widgets P&C > Specification, as well as a bunch of examples (which are wrong, so I > would really appreciate some help with these!). > > The dir attribute is specified here: > http://dev.w3.org/2006/waf/widgets/#global-attributes > > The span element is specified here: > http://dev.w3.org/2006/waf/widgets/#the-span-element > > The processing step that defers to the yet to be written [WIDGET-BIDI] > specification is defined here: > http://dev.w3.org/2006/waf/widgets/#rule-for-getting-text-content > > The specification makes it mandatory that a user agent implement the > WIDGET-BIDI spec: > > "A user agent is an implementation of this specification that also > supports [XML], [XMLNS], [UTF-8], [DOM3CORE], [SNIFF], [WIDGETS-BIDI], > and [ZIP]..." > > We would appreciate your review and any assistance you can provide. > In particular, we would appreciate your guidance into what would go > into the Widgets Bidi specification (i.e., how processing is done for > dir and span). At the moment, we only have the following text for such > a specification (based on HTML5's bdo element): > > [[ > If an element has the dir attribute set to the exact value ltr, then > for
RE: [widgets] Testing ITS support
Hello Marcos, As a first step, could you take a look at our dir tests for HTML and see if there's anything there that could be adapted? Go to http://www.w3.org/International/tests/list-html-css#direction Cheers, RI Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/ > -Original Message- > From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core- > requ...@w3.org] On Behalf Of Marcos Caceres > Sent: 27 November 2009 10:15 > To: public-i18n-c...@w3.org > Cc: public-webapps > Subject: [widgets] Testing ITS support > > Dear i18n WG, > During the call to transition the Widgets Packaging and Configuration > specification (P&C) [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/
Comments on Last Call Working Draft of XHR
Hopefully you'll get a formal response from the i18n WG shortly. In the meantime, I have only a couple of personal editorial suggestions: [1] 2.2 terminology It would help a lot to link each of the terms defined in html5 to the appropriate location in the html5 spec, if possible. [2] same section I was confused by the term "document's character encoding". I suspect this ought to be "character encoding (of the document)", where the parenthesised text is non-bold. The problem was that I thought "document's character encoding" was a single term, like "URL character encoding", and was something different than "character encoding" (in the same way that "document character set" is different from "character set"). Hope that helps, RI Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/ Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/
RE: [WIDGET PC] i18n comment 6: Use of its:dir
Hi Marcos, Without understanding why folks think these things, it's a little difficult to provide specific discussion points, but the key point behind ITS is that it describes types of information you need for a well-internationalized and easily localizable specification. The implementation of those ideas is secondary. One such type of information relates to bidi support. If your markup is to support use for the languages of the millions of people who use a script such as Arabic, Hebrew, Thaana, N'ko, etc, you need to provide a simple way to set and change the base direction for parts of the document. It is important for that information to be inherited through contained elements - you can't do that using Unicode controls. Markup is also preferable to control codes because it makes editing and maintenance of code much easier. ITS happens to suggest a name for the its:dir attribute and describe what values you'd need, and what that means. But it's not about supporting ITS here. It's about providing a mechanism for people using right-to-left and particularly bidirectional text to achieve what they need to. I don't think that is optional. Call the attribute whatever you want, I believe you need it and its behaviour to be available to users. I didn't review the Widgets spec myself (we have so much to cover that we have to share things around), but I'm starting to think maybe I should try to find the time, if I can. For example, I noticed that the its:dir attribute can be used on the name, author, and description elements, but I would have expected that for a widget in Persian, say, you'd just set the attribute on the widget element and it should take care of all those without the author having to separately and laboriously markup them up. (Think about HTML - you put dir on the html element, not on every p, div, list, etc.) You'd only need to use dir on name, author, span, etc if you need to *change* the base direction. (We had a similar gap in SVG Tiny markup before Xmas, which they fixed as soon as we pointed it out to them.) Well, I hope that's of some use. I'll try to take another look next week, if I can. Cheers, RI Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/ > -Original Message- > From: Marcos Caceres [mailto:marc...@opera.com] > Sent: 10 July 2009 16:49 > To: Phillips, Addison > Cc: ish...@w3.org; public-Webapps@w3.org; public-i18n-c...@w3.org > Subject: Re: [WIDGET PC] i18n comment 6: Use of its:dir > > > > On 7/10/09 5:40 PM, Phillips, Addison wrote: > > (personal response) > >> Fantastic. Unfortunately, implementer feedback has raised concerns > >> about ITS and so the WG has put ITS features "at risk" (and marked > >> as > >> such in the soon to be released CR spec). We will see what happens > >> in > >> CR; hopefully implementers will understand the value of > >> implementing > >> it. > >> > > > > I noticed that in the transreq. Obviously the I18N WG is concerned about > any such feedback: can webapps please share what the concerns are? I know > that many developers consider bidi support "kind of scary"; I hope that the > implementation issues are not simply fear driven. Is there some way that the > Internationalization community can support implementers? > > > > The concerns are that people won't implement ITS (or that authors can > use the appropriate Unicode markers to achieve the same thing as ITS). > > Kind regards, > Marcos
[WIDGET URI] i18n comment 1: URI Spec
Comment from the i18n review of: http://www.w3.org/TR/2009/WD-widgets-uri-20090618/ Comment 1 At http://www.w3.org/International/reviews/0907-widgets/ Editorial/substantive: S Tracked by: AP Location in reviewed document: - Comment: We second Martin's comments at http://lists.w3.org/Archives/Public/public-i18n-core/2009AprJun/0067.html. The term URI appears to mean URI and *not* IRI universally here. No non-ASCII paths are given in examples and the relationship to IRI is not specified. The Packaging and Configuration spec mentions encodings and permits the full range of Unicode in file names, so the lack of specificity is at least an oversight. I suspect that, depending on the use of the URI, they really do mean IRI here, though. Packaging and Configuration strongly suggests the use of the UTF-8 encoding for Zip relative paths and human-readable (native encoded) URIs would be more in keeping with the usability desires of web-apps.
[WIDGET PC] i18n comment 7: Step not necessary?
Comment from the i18n review of: http://www.w3.org/TR/2009/WD-widgets-20090528/ Comment 7 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: AP Location in reviewed document: Section 9.1, step 4 [http://www.w3.org/TR/2009/WD-widgets-20090528/#step-4--locate-and-process-the-digital-s] Comment: In this same step, substep 4 is unnecessary. It does save processing time, but it is not required for proper operation. Performing the specific change suggested also has the negative side-effect of altering the user's preferences ahead of the local configuration. The rightmost occurrence would be a better choice for elimination.
[WIDGET PC] i18n comment 6: Use of its:dir
Comment from the i18n review of: http://www.w3.org/TR/2009/WD-widgets-20090528/ Comment 6 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: AP Location in reviewed document: Section 9.1, step 5 [http://www.w3.org/TR/2009/WD-widgets-20090528/#step-5--derive-the-user-agents-locale] Comment: its:dir appears in this document and is a good illustration of its proper use, as does xml:lang. See, for example, section 8.8.
[WIDGET PC] i18n comment 5: Too small arbitrary limit on locale ids
Comment from the i18n review of: http://www.w3.org/TR/2009/WD-widgets-20090528/ Comment 5 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: S Tracked by: AP Location in reviewed document: Section 9.1, step 5 [http://www.w3.org/TR/2009/WD-widgets-20090528/#step-5--derive-the-user-agents-locale] Comment: In Step 5 of section 9.1, we find an arbitrary limit on locale identifiers (BCP 47 language tags): Each item in the unprocessed locales must be a string shorter than eight characters, in lowercase form, that conforms to the production of a Language-Tag, as defined in the [BCP47] specification. This limit is too short for even some simple language tags. Consider "zh-Hant-CN", which is given as an example in the document: it has 10 characters. This limit really should be removed. The eight character limit is on subtags.
[WIDGET PC] i18n comment 4: Various positive observations
Comment from the i18n review of: http://www.w3.org/TR/2009/WD-widgets-20090528/ Comment 4 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: AP Location in reviewed document: Section 8.3 [http://www.w3.org/TR/2009/WD-widgets-20090528/#attribute-types] Comment: its:dir appears in this document and is a good illustration of its proper use, as does xml:lang. See, for example, section 8.8. The 'charset' attribute appears in the element and appears to be properly specified The element appears in the document and appears to be properly specified.
[WIDGET PC] i18n comment 3: Widget metadata
Comment from the i18n review of: http://www.w3.org/TR/2009/WD-widgets-20090528/ Comment 3 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: AP Location in reviewed document: Section 8.3 [http://www.w3.org/TR/2009/WD-widgets-20090528/#attribute-types] Comment: The metadata does successfully incorporate our comments that multiple languages should be allowed on those attributes that make sense with them.
[WIDGET PC] i18n comment 2: Clarify IRI/URI
Comment from the i18n review of: http://www.w3.org/TR/2009/WD-widgets-20090528/ Comment 2 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: AP Location in reviewed document: Section 8.3 [http://www.w3.org/TR/2009/WD-widgets-20090528/#attribute-types] Comment: Section 8.3 (Attribute Types) contains a subsection called "URI Attribute" which is relevant to our comment above. It says: -- An attribute defined as containing a valid URI. A valid URI is one that matches the URI token of the [URI] specification or the IRI token of the [RFC3987] specification. The value of this kind of attribute is retrieved using the rule for getting a single attribute value. -- This is problematical, since all URIs are IRIs, but not the converse. We think this should favor IRI and note the relationship to URI.
[WIDGET PC] i18n comment 1: Wrong language tag.
Comment from the i18n review of: http://www.w3.org/TR/2009/WD-widgets-20090528/ Comment 1 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: AP Location in reviewed document: Section 7.2 [http://www.w3.org/TR/2009/WD-widgets-20090528/#examples] Comment: The simple example in Section 7.2 still contains an error. The language tag for Spanish is "es", not "sp". It is shown correctly in the graphic but not the title of the section or elsewhere in the text.
