W3C home > Mailing lists > Public > public-i18n-core@w3.org > October to December 2011

[Bug 10830] i18n comment : Please add support for rb

From: <bugzilla@jessica.w3.org>
Date: Sun, 18 Dec 2011 18:42:10 +0000
To: public-i18n-core@w3.org
Message-Id: <E1RcLgY-0001Sm-Of@jessica.w3.org>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10830

--- Comment #76 from Richard Ishida <ishida@w3.org> 2011-12-18 18:42:08 UTC ---
In an attempt to help this discussion forward i have prepared a wiki page. It
attempts to state use cases, and from there to show alternative proposals for
addressing those use cases (with examples). For each proposal there is a short
summary of pros and cons.

See http://www.w3.org/International/wiki/Rb

This looks at the question of whether rb is needed by taking into account the
larger perspective of the ruby model.

There is also a new set of tests, with results summarised for major desktop
browsers, at
http://www.w3.org/International/tests/html-css/ruby/results-ruby-markup (Most
of the tests are exploratory in nature.)

>From doing this exercise, I am beginning to lean towards the following views:

a. legacy usage of rb is not a strong persuader for adding rb to html5
b. we can probably do without rb for simple ruby (since we can use span inside
html5 ruby). This includes jukugo ruby.
c. we have a couple of options to follow for supporting double-sided (ie.
complex) ruby. This impinges also, however, upon the handling of fallbacks,
which is currently an issue with the html5 model. Fantasai proposes a model
which provides a simple, consistent solution to both problems, but which does
require the introduction of rb (and rtc). There may be a number of workarounds
that could be cobbled together for double-sided ruby if we absolutely want to
avoid rb, but they don't solve the fallback issue.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Sunday, 18 December 2011 18:42:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:23:07 UTC