Re: [nvda-translations] [NVDA-dev] Korean translation so far was:main 5473
- From: "Joseph Lee" <joseph.lee22590@xxxxxxxxx>
- To: "'NVDA screen reader development'" <nvda-dev@xxxxxxxxxxxxxxxxxx>
- Date: Fri, 21 Sep 2012 04:11:03 -0700
Hi folks, mostly Asian translators,
I'm also sending this to translation mailing list to gather wider feedback:
Here are works done so far with NvDA Korean translation:
* I'm using source code version, as eSpeak 1.46.02 does not include Korean
voice - the latest dev version (1.46.26) does include Korean voice. However,
since the original data was produced by a Chinese person, I modified the
data to fit Korean pronunciation rules. Also, since Peter V told devs that
eSpeak has added something new in source code, I applied the patch from him
to allow string pointers to work. Still, Korean users felt that it wasn't
adequate, so we decided to go with Ms Speech Platform and some SAPI Korean
voice along with Vocalizer as an alternative option (to be added as an NvDA
add-on in case of Vocalizer), as we fear that NvDA would get negative
reviews due to eSpeak's pronunciation oddities. By the way, the individual
who provided Korean data also said that he had Japanese eSpeak data as well.
As for translation work so far: as of Beta 4 of Korean release, we have:
* Interface and user guides were translated (Beta 1 and Beta 2).
* Hanja (Chinese character) input/output functionality has been added (Beta
4) based on a database of 7700+ Hanja characters found by one of the Korean
translators.
* Understandable Korean voice has been added to eSpeak (beta 3 with various
refreshes to gather user feedback). For now, it was decided to halt this
process since it might be difficult (for now) to optimize eSpeak's
pronunciation rules to Korean. We'll resume work when experts come in.
* Korean braille is being developed (to be included in beta 5). We plan to
test it using Braille Sense family.
As for Hanja functionality: we're using both synbols.dic and
characterDescriptions.dic for this purpose: symbols.dic contains
pronunciation for individual Hanja characters, and characterDescriptions.dic
contains Korean meanings for each Hanja character. One of the challenges has
been to find a way to provide single pronunciation for multiple Hanja
characters; in the end, it was decided to write all 7700+ chars in
symbols.dic file with pronunciation for each one (since Vocalizer and eSpeak
does not ship with Hanja rules). During this process, we took a look at both
Chinese and Japanese symbols and char descriptions file to understand how
these language teams did it.
Thanks. Hope this gives you a picture of what's going on.
//JL
-----Original Message-----
From: nvda-dev-bounces@xxxxxxxxxxxxxxxxxx
[mailto:nvda-dev-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of Takuya Nishimoto
Sent: Friday, September 21, 2012 3:44 AM
To: NVDA screen reader development
Subject: Re: [NVDA-dev] Branch nvda/main: Rev 5473: Only automatically
report all candidates in a candidate list if the candidate list has more
than one item. If only 1, it should not be repeated twice. Also place a
final comma (, ) after the last candidate w
Hello Joseph and Mick,
Regarding character review, description and input candidates, I would like
to give information of Japanese Language support.
As you know, NVDA Japanese team is developing NVDA Japanese version and also
supporting East Asian enhancement works.
I am interested in the work of Korean translators.
To support Japanese language, some kind of short character descriptions
(other than longer description in
characterDescriptions.dic) should be provided, which are similar to the
symbols.dic enhancements of Hanja by Korean team.
The reason is that 'spelling functionarity' or <spell> markup does not work
properly with most of Japanese speech synthesizers, and also some (mostly
phonetic) characters for Japanese language should always be described using
dictionary.
However, if we do in the same way, speakText functionality does not work
correctly, because symbols.dic replace the string globally.
In most cases, pronunciations of characters should be given under the
consideration of context, especially for Japanese language.
Regarding Japanese language support, we think enhancement should be required
for spelling functionality of speech module, rather than adding symbol
descriptions.
Our modifications related to the issue is not internationalized so far,
however, if some sort of enhancements can cover the requirements of both
Japanese and Korean, we will be happy to make future joint work.
Regarding to automatic reporting candidates, the users of Japanese input
methods does not use this feature at all.
If the candidates are reported using character descriptions, it is not
necessary for Japanese language users.
This is because the candidate window of Japanese input method usually opens
when the second candidate is shown, and only description of second candidate
should be reported at the moment.
I understand that the requirements of Chinese, Japanese and Korean are
different regarding this.
Please see information regarding NVDA Japanese:
http://en.nishimotz.com/nvdajp_workshop
Best regards,
--
Takuya Nishimoto
2012/9/21 Joseph Lee <joseph.lee22590@xxxxxxxxx>:
> Hi mick,
> This was brought up as a result of including Hanja characters - as you
> may know, many Hanja chars are pronounced the same. For example, the char
"soo"
> (Korean entry: tn) has multiple meanings (it could be "water" or
"number").
> So when a Korean user types tn (soo) and wishes to convert this to
> Hanja (Chinese character) using right control key with auto reporting
> of candidates enabled, he or she will here:
> 1. soo.
> 2. soo.
> 3. soo.
> and so forth. On the screen, the different Hanja versions of the word
"soo"
> will be displayed. The reasoning for the below suggestion was to allow
> Korean users to hear the description of char descriptions without
> having to arrow up and down the list. In the end, it could sound like:
> 1. Moor soo (water).
> 2. soo soo (number)
> With auto reporting of candidates enabled.
> Another example: suppose a Korean user wishes to write Hanja for prize
> (Korean: sang, entry: tkd). The word "sang" has multiple Hanja
> interpretations - it could mean "prize", or it could mean "above". A
> typical keyboard entry would go like this:
> 1. Switches to Korean input and types tkd.
> 2. When the unicode char for "tkd" is spoken, press right control key
> to bring up candidates list. With auto reporting on, user would hear: "1.
> sang", "2. sang", and so forth (in our case, the unicode symbol value
> for these chars).
> 3. In typical case, user would wish to hear (with auto reporting of
> candidates on and when candidate lists is open): "1. we sang" (above), "2.
> sang sang" (prize) and so forth without having to use arrow keys to
> select each item, as the user can enter the desired entry number upon
> hearing the desired descriptions.
> As for Hanja database, one of the Korean translators gave me a list of
> 7000 or so Hanja characters. We're using symbols.dic for actual symbol
> pronunciation and characterDescriptions.dic for char meanings.
> Thanks.
> //JL
>
>
>
>
>
>
> -----Original Message-----
> From: nvda-dev-bounces@xxxxxxxxxxxxxxxxxx
> [mailto:nvda-dev-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of Michael
> Curran
> Sent: Thursday, September 20, 2012 11:04 PM
> To: NVDA screen reader development
> Subject: Re: [NVDA-dev] Branch nvda/main: Rev 5473: Only automatically
> report all candidates in a candidate list if the candidate list has
> more than one item. If only 1, it should not be repeated twice. Also
> place a final comma (, ) after the last candidate when a
>
> Hi Joseph,
>
> To hear character descriptions, either use object navigation to move
> to each candidate, or it may be possible to use the arrow keys to
> select each candidate as well. However, auto reporting of candidates
> should be nice and quick. If character descriptions were included this
> would be too slow. This decision has worked well for both Chinese and
Japanese.
> But, if you strongly feel you can make a good case for another option,
> then please provide further info.
>
> Mick
>
>
>
>
> On 9/21/2012 3:30 PM, Joseph Lee wrote:
>> Hi,
>> Regarding candidate reporting: Korean users reports that, when
>> candidates
> are reported (with auto reporting of candidates enabled), they hhere
> only symbols, not character descriptions associated with them as with
> other screen readers, and suggested that we should allow char
> descriptions to be spoken, or perhaps provide a combo box to specify
> how much info is spoken with auto reporting of candidates. Thanks.
>> //JL P.S. Testing Korean version via source code and using dev
>> version of
> eSpeak.
>>
>> -----Original Message-----
>> From: nvda-dev-bounces@xxxxxxxxxxxxxxxxxx
> [mailto:nvda-dev-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of NV Access
> bazaar commits
>> Sent: Thursday, September 20, 2012 10:26 PM
>> To: nvda-dev@xxxxxxxxxxxxxxxxxx
>> Subject: [NVDA-dev] Branch nvda/main: Rev 5473: Only automatically
>> report
> all candidates in a candidate list if the candidate list has more than
> one item. If only 1, it should not be repeated twice. Also place a
> final comma (, ) after the last candidate when autom
>>
>> At http://bzr.nvaccess.org/nvda/main
>>
>> ------------------------------------------------------------
>> revno: 5473
>> revision-id: mick@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> parent: jamie@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> committer: Michael Curran <mick@xxxxxxxxxx> branch nick: main
>> timestamp: Tue 2012-09-18 00:22:23 +1000
>> message:
>> Only automatically report all candidates in a candidate list if
>> the
> candidate list has more than one item. If only 1, it should not be
> repeated twice. Also place a final comma (,) after the last candidate
> when automatically reporting to separate it from the further
> announcement of the actual focused candidate.
>>
>>
>> _______________________________________________
>> NVDA-dev mailing list
>> NVDA-dev@xxxxxxxxxxxxxxxxxx
>> http://lists.nvaccess.org/listinfo/nvda-dev
>>
>
> --
> Michael Curran
> Director, NV Access Limited
> www.nvaccess.org
> Ph +61 7 5667 8372
>
> _______________________________________________
> NVDA-dev mailing list
> NVDA-dev@xxxxxxxxxxxxxxxxxx
> http://lists.nvaccess.org/listinfo/nvda-dev
>
>
> _______________________________________________
> NVDA-dev mailing list
> NVDA-dev@xxxxxxxxxxxxxxxxxx
> http://lists.nvaccess.org/listinfo/nvda-dev
_______________________________________________
NVDA-dev mailing list
NVDA-dev@xxxxxxxxxxxxxxxxxx
http://lists.nvaccess.org/listinfo/nvda-dev
Other related posts:
- » Re: [nvda-translations] [NVDA-dev] Korean translation so far was:main 5473 - Joseph Lee
