From: Frank Yung-Fong Tang (ytang0648@aol.com)
Date: Wed Dec 03 2003 - 18:38:35 EST
Peter Kirk wrote:
> On 02/12/2003 16:25, Frank Yung-Fong Tang wrote:
>
> >...
> >"a barrier to proper internationalisation" ?
> >
> >My opinion is reverse, I think it is a "strategy to proper
> >internationalization". Remember, people can always choose to stay with
> >ISO-8859-1 only or go to UTF-8 with MES-1 support for European market.
> >UTF-8 with MES-1 support does not mean other characters won't work in
> >their product, but instead, it mean other charactrers are not Quality
> >Assuranced in their products.
> >
> >
> Well, Frank, I am surprised that you favour encouraging developers to
> design their systems with only the European market in mind. Surely it
> would help with internationalisation for Thailand if the system is
> designed with support for Thai and other scripts in mind, even if not
> fully implemented and quality assured in the first release.
No. that is not what I said. See, you still thinking about "developers"
and "design" and "system". I am talking about "QA", "product",
"service", "marketing" PLUS the development.
I am encouraging QA to test MES-1 with UTF-8 instead of only ISO-8859-1.
I am encouraging product ship with MES-1 support out of the box instead
of ISO-8859-1.
And if QA wrote their test plan by using UTF-8 and MES-1 and product
claim to supprt MES-1, how far it could be away from "even if not
fully implemented and quality assured in the first release."
You are talking about a "developer driven mindset", I am talking about a
"product driven", "marketing driven", "Quality driven" mindset.
>
> >...
> >You only look at the issue from the developer point of view. But how
> >about QA? How are you going to QA the whole Unicode? You also need to
> >look at the issue from an end-user point of view, or the "working out of
> >box" point of view. How could the end user know what kind of function
> >they are going to get WITHOUT extra efforts.
> >
> >
> True, I hadn't looked at the QA issue. I suppose there are two ways to
> go here: one would be to aim at support for the whole of Unicode but
> only assure support for certain ranges;
in my book "a supporting feature without QA is not a supported feature
at all". See, you still have this "developer oriented" mind set. No
"product" should claim they support something without QA.
> the other is for the QA people
> to work with third party fonts.
> QA-ing the whole of Unicode shouldn't be
> a big problem anyway as most work needs to be done on new features
> rather than new characters e.g.
For QA engineer to test a software product with a particular script,
they have to have at least some minimun knowledge about that script. And
I won't say that is easy. For example, ask yourself, how many scripts
you feel confortable by youself to Quality Assuranced? (not just test,
but ASSURANCE)
> if one script using special feature X is
> assured to work, a rather quick test should be sufficient to show that
> every script using feature X works.
hum.... that sound below the QA standard normal QA engineers is
targeting. A good Test Plan need to include
Make sure right input cause right output
Make sure wrong input cause error but not rigth output
Make sure all the possible cdoe path got executed.
and more.
>
> >If you are a QA engineer who is working on a working out of box product,
> >how are you going to prepare your test cases? If you are a product
> >marketing person who is going to write a product specification about a
> >cell phone which do not allow user to download fonts, how are you going
> >to spec it out?
> >
> >
> Well, I was thinking of computers rather than brain dead mobile phones.
> Mobile phones have long allowed downloading of ring tones, so why not
> downloading of fonts? And there is probably already a significant demand
> for mobile phones using every script which is in current everyday use,
> and so mobile phone manufacturers who restrict users to more restrictive
> subsets are being shortsighted - although I would expect that full BMP
> support would be adequate for a basic product in this scenario.
>
Name me a cell phone which can download and accept CJK Han Extension B
(Unicode Plan 2) today.
If you are building a theory, you can support any unicode code point.
If you are building a technology, you may support any unicode code point.
If you are building a product, you won't be able to support any unicode
code point with limited time & cost in good enough quality. In that
case, I rather cut features (how many scripts in Unicode) in exchange of
quality.
> >You are assuming a product which is does not need to work "out of box".
> >If that is the case, you can ALSO think Windows 2000 work for surrogate
> >since you can install or tweak the register to make it work with
> >Surrogate. You can ALSO think Windows 95 can support Complex Script
> >since you can INSTALL Uniscribe on it, right?
> >
> >
> Right. My Windows 2000 supports surrogates, probably because either one
> of the service packs or Office XP installed this support for me. When I
> was using Windows 95 I could use complex scripts in IE5 and Office 2000
> - the required support (Uniscribe etc) was installed with these
> programs. These are things which should be supported out of the box,
> although they were not quite in Windows. I am realising that certain
> scripts may not have font support out of the box, but that is something
> which can easily be remedied.
If "work out of the box" is not the requirement in your arguement, then
any software today already can claim that they could support every
Unicode since in theory you can always produce a patch for that if
someone is willing to spend time to produce them, as you.
>
> --
> Peter Kirk
> peter@qaya.org (personal)
> peterkirk@qaya.org (work)
> http://www.qaya.org/
>
>
-- -- Frank Yung-Fong Tang Šýštém Årçhîtéçt, Iñtërnâtiônàl Dèvélôpmeñt, AOL Intèrâçtívë Sërviçes AIM:yungfongta mailto:ytang0648@aol.com Tel:650-937-2913 Yahoo! Msg: frankyungfongtan
This archive was generated by hypermail 2.1.5 : Wed Dec 03 2003 - 19:33:09 EST