Hi folks,
I’m copying both the translations and dev_asia group to get your
feedback on the following:
Are there languages besides Korean that requires multiple char
components when constructing a single char? At least in Korean, there
are character components that goes into creating a single character (not
a word). In Korean, a single character consists of initial conscenant,
one or two vowels and zero or more final conscenants. For example, the
character “ga” (written as ㄱㅏin Korean) has an initial conscenant (G,
pronounced “gi-yug) and a vowel (ah). Or, the character “gwan” (written
as 관 in Korean, meaning a crown) has the initial conscenant of “G”, the
vowel “wa” and the final conscenant of “n” (pronounced “ni-eun”).
As of 2012.3, when invoking char description script (numpad2 twice
quickly when the review cursor is focused on the character), the char
itself is announced again (when the char in question is a Hangul
character). The ideal behavior (requested by Korean users) is to
announce the components of such a character when this script is
executed. For example, supposing that the char is “ga”:
User puts review cursor on the char “ga”. Then he or she does the following:
Current behavior under 2012.3:
·Presses numpad2: NVDA says “ga”.
·Presses Numpad2 for the second time: NvDA says “ga”.
Ideal behavior (investigating for and researching this with Korean users
for 2013.1):
·Presses Numpad2: NvDA says “ga”.
·Presses Numpad2 for the second time: NvDA says “gi-yuk, ah”.
A naïve solution would be to map all possible 10773
conscenant/vowel/conscenant set combinations in
characterDescriptions.dic, which has a risk of slower performance. A
fellow Korean translator says he found a Python script which could
calculate components of a Korean char. I feel that if this is unique to
Korean, then it’s something that we Korean users can work on it
ourselves; however, if there are other languages that uses this kind of
component system for constructing a char, that could give us some test
scenarios for improving char description module in the future to take
this case into account.
If you want, I’ll create a ticket for this case later this month. Thanks.
//JL
_______________________________________________
Nvda-dev-asia mailing list
Nvda-dev-asia@xxxxxxxxxxxxxxxxxx
http://lists.nvaccess.org/listinfo/nvda-dev-asia
