Thai issue for 2.0 timeframe
mark...@gmail.com
be .general, not .18n.
At present, Thai support in Mozilla products is lacking [1]. Since Thai
is one of major Asian language (65M speakers), this make us miss the
oppotunity to promote use of Firefox/Thunderbird in Thailand. Since we
have both i18n technical problems and Mozilla policy problems so that
I'll address them here.
Let me introduce Thai writing system in brief. Thai has no space
between words, just between sentences only and it needs extra
library/dictionary to handle line-breaking problem. Browser without
line-breaking features is neary unusable for Thai people and this adds
more complexity to i18n/l10n level than tranlation.
I separate Thai i18n/l10n problems into two main issues:
- Translation
- Line-breaking and other technical i18n issues
Thai Translation of Firefox and Thunderbird are done and distributed
widely among Thai users. They are in process to commit on Mozilla.org
CVS.
There are many attempt to solve Thai line-breaking and several patches
available [3]. Unfortunately due to infrastructure limitation, we don't
have a final solution which works all platform. Current workaround is
Thai Community Edition [2] which patched by using extra library such as
ICU [4][5].
The downside of Community Edition is developer needs to rebuild
everytime new version is released. The other downside is public
awareness that Thai Community Edition exists. Some Thai people may hear
about Firefox coolness and directly to grab official build and discover
there can't handle line-breaking.
The sustain solution for this problem is waiting for infrastructure
change by using Cairo for rendering. This change will coming in Firefox
3.0, so we will miss this in 2.0 timeframe.
I propose some idea for this problem
- In long term, delay official Thai localization build (in [1]) until
we solve line-breaking problem in trunk
- In short term, use unofficial or Community Edition builds instead but
point to these build clearly on any related Mozilla webpages. Now we
have central Firefox Thai site [6] that links to all available builds
but I think host this page on Mozilla web site is better.
Can this possible for Mozilla process?
Isriya Paireepairit
[1] http://www.mozilla.com/firefox/all.html
[2] http://www.osdev.co.th/firefox/ (in Thai
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=7969
[4] http://icu.sourceforge.net/
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=299324
[6] http://linux.thai.net/plone/TLWG/firefox-thai (in Thai)
Thai tracking bug is https://bugzilla.mozilla.org/show_bug.cgi?id=65896
Gen Kanai
(Japanese and Chinese are both the same in that regard, plus other
Asian languages I am sure.)
Please let me know if Mozilla Japan can help answer any questions you
may have about line breaking in Asian Mozilla browsers. Anything we
can do to help, we will do our best.
Sincerely,
Gen Kanai
Mozilla Japan
Philip Chee
> Thai is not the only Asian language without spaces between words
> (Japanese and Chinese are both the same in that regard, plus other
> Asian languages I am sure.)
Thai has different problems. In Chinese each ideograph is a separate
word (let's ignore compounds for the moment). In Japanese you can look
at the state change from kana to kanji to detect word boundaries. Thai
uses an alphabet but doesn't use spaces between words.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]Why are Chinese fortune cookies written in English?
* TagZilla 0.059
Jean-Marc Desperrier
> Please let me know if Mozilla Japan can help answer any questions you
> may have about line breaking in Asian Mozilla browsers. Anything we
> can do to help, we will do our best.
Follow-up to this message restricted to the i18n group.
Kanai, if you know any limitation in the line breaking of Mozilla for
Asian language, please signal it.
About japanese, I'd just signal the current line breaking implementation
in Mozilla is called nsJISx4501LineBreaker.cpp.
As you can deduce, this means it's implementing it by following the
Japanese Industrial Standards Committee recommendation JIS X 4501 1995,
so it should take care of Japanese quite properly.
Jean-Marc Desperrier
> I've talked with Axel Hecht and he think the appropriate group should
> be .general, not .18n.
>
> Thai Community Edition [2] which patched by using extra library such as
> ICU [4][5].
>
> about Firefox coolness and directly to grab official build and discover
> there can't handle line-breaking.
>
> The sustain solution for this problem is waiting for infrastructure
> change by using Cairo for rendering. This change will coming in Firefox
> 3.0, so we will miss this in 2.0 timeframe.
This is not that guaranteed to change in Cairo/FF 3. It depends on what
ROC implements and he said in the comment of his blog :
http://weblogs.mozillazine.org/roc/archives/2006/02/post_1.html
"It might make sense to eventually get line-breaking information from
UPA. However, ultimate control has to stay with nsTextFrame so we can do
hyphenation, CSS 'whitespace', and other effects. Given that, the
simplest thing to do for now, while we get everything else working, is
to keep on getting line-break information the way we currently do."
I think it's worth insisting that FF 3 needs UPA level line-breaking.
> I propose some idea for this problem
> - In long term, delay official Thai localization build (in [1]) until
> we solve line-breaking problem in trunk
> - In short term, use unofficial or Community Edition builds instead but
> point to these build clearly on any related Mozilla webpages. Now we
> have central Firefox Thai site [6] that links to all available builds
> but I think host this page on Mozilla web site is better.
>
> Can this possible for Mozilla process?
I really think that what makes sense is to have the official Thai
release include the patch you have now in the Community Edition, even if
they are not in trunk.
I hope you have success in convincing MoFo that something needs to be
done in that line.
Axel Hecht
> mark...@gmail.com wrote:
>> I've talked with Axel Hecht and he think the appropriate group should
>> be .general, not .18n.
>>
>> [...] Current workaround is
>> Thai Community Edition [2] which patched by using extra library such as
>> ICU [4][5].
>>
>> [...] Some Thai people may hear
>> about Firefox coolness and directly to grab official build and discover
>> there can't handle line-breaking.
>>
>> The sustain solution for this problem is waiting for infrastructure
>> change by using Cairo for rendering. This change will coming in Firefox
>> 3.0, so we will miss this in 2.0 timeframe.
>
> This is not that guaranteed to change in Cairo/FF 3. It depends on what
> ROC implements and he said in the comment of his blog :
> http://weblogs.mozillazine.org/roc/archives/2006/02/post_1.html
>
> "It might make sense to eventually get line-breaking information from
> UPA. However, ultimate control has to stay with nsTextFrame so we can do
> hyphenation, CSS 'whitespace', and other effects. Given that, the
> simplest thing to do for now, while we get everything else working, is
> to keep on getting line-break information the way we currently do."
>
> I think it's worth insisting that FF 3 needs UPA level line-breaking.
I think that it's worth to keep in mind that we need hooks to support
thai-enabling extensions, if the general world wouldn't want to suffer
from a recognizable perf hit here.
But yes, I have the recollection that roc didn't promise to fix thai
with his stuff.
>> I propose some idea for this problem
>> - In long term, delay official Thai localization build (in [1]) until
>> we solve line-breaking problem in trunk
>> - In short term, use unofficial or Community Edition builds instead but
>> point to these build clearly on any related Mozilla webpages. Now we
>> have central Firefox Thai site [6] that links to all available builds
>> but I think host this page on Mozilla web site is better.
>>
>> Can this possible for Mozilla process?
>
> I really think that what makes sense is to have the official Thai
> release include the patch you have now in the Community Edition, even if
> they are not in trunk.
> I hope you have success in convincing MoFo that something needs to be
> done in that line.
I personally don't think that we should make official patched builds.
That said, I haven't heard back from my own inquiry on priorities for
thai in relation to firefox milestones, so I'm still in the open.
I do think though that we may want to discuss a way of adding this
community edition to the all.html page.
But that is just my opinion, not a mozilla.com product placement thing.
Axel
mark...@gmail.com
Isriya
Robert O'Callahan
> This is not that guaranteed to change in Cairo/FF 3. It depends on what
> ROC implements and he said in the comment of his blog :
> http://weblogs.mozillazine.org/roc/archives/2006/02/post_1.html
>
> "It might make sense to eventually get line-breaking information from
> UPA. However, ultimate control has to stay with nsTextFrame so we can do
> hyphenation, CSS 'whitespace', and other effects. Given that, the
> simplest thing to do for now, while we get everything else working, is
> to keep on getting line-break information the way we currently do."
>
> I think it's worth insisting that FF 3 needs UPA level line-breaking.
I'm sure we'll be happy to accept a patch...
In the new world we construct UPA (Uniscribe/Pango/ATSUI) textrun
objects only for spans of consistently styled text. For Thai line
breaking I assume we need to analyze text runs containing text with
different styles, which would be a big performance hit if we don't need
it. So I think that even if we get linebreak information from UPA, we'll
get it via a different interface than the gfxTextRun interface we're
using to render with UPA.
Rob
Gervase Markham
> There are many attempt to solve Thai line-breaking and several patches
> available [3]. Unfortunately due to infrastructure limitation, we don't
> have a final solution which works all platform. Current workaround is
> Thai Community Edition [2] which patched by using extra library such as
> ICU [4][5].
>
> The downside of Community Edition is developer needs to rebuild
> everytime new version is released. The other downside is public
> awareness that Thai Community Edition exists. Some Thai people may hear
> about Firefox coolness and directly to grab official build and discover
> there can't handle line-breaking.
IMO, mozilla.org should not be shipping any sort of Thai build which
doesn't support proper Thai line-breaking. As you point out, this is a
recipe for a bad user experience.
We need to either:
a) Start shipping builds with the relevant patches
b) Stop shipping Thai builds altogether (i.e. drop Thai support)
c) Start pointing Thai users at the Community builds
> - In short term, use unofficial or Community Edition builds instead but
> point to these build clearly on any related Mozilla webpages. Now we
> have central Firefox Thai site [6] that links to all available builds
> but I think host this page on Mozilla web site is better.
I think option a) is the right option - i.e. fix bug 299324 and other
related bugs, and build the Thai version with ICU turned on.
Whether this can be managed in time for Firefox 2.0 is a different
question, of course.
Gerv