Hi, Thank you for your reviewing again. No, it is almost rewriting rather than reviewing. Updated. http://anonscm.debian.org/gitweb/?p=collab-maint/uim.git;a=blob;f=debian/control;h=40fbbc940b4085cff7b19fb3b53439780dd236b7;hb=78581cd7d4ed19b59fbee8164c95c0ad32182c96 On Mon, Jun 20, 2011 at 10:53:08AM +0100, Justin B Rye wrote: > > Upstream says "uim" is not "UIM". So, I did s/UIM/uim/g. > > But note that they use "Uim" at the beginning of a sentence. Fixed. > >> +# but what does the "Pinyin [...] Hangul [...]" bit actually mean? > > > > Do you mean "Why do Pinyin and Hangul have explanation such as Chinese/Korean > > input method? Anthy, SKK, Canna and T-Code/TUT-Code are just proper noun"? > > Do I have to add explanation for all input methods? > > Or remove Pinyin and Hangul explanations? > > Go back a step. You also need to explain that: > (a) the list is a list of input methods; > (b) "Pinyin (Chinese input method)" is short for "which is an input > method for Chinese" (and likewise for Korean); and > (c) the default "explanation" for items that don't have one is > "(which is an input method for Japanese)". > None of this is obvious to readers who don't already know it! After > all, pinyin, hangul, and IPA weren't invented as "input methods"; > they're scripts. Yes, Pinyin is *also* the name of an input method, > but it's not self-evident that this is what you're saying. I see. I must get rid of my prejudices and take readers side. > Trying to make this clearer, I'd suggest something like: > > Uim is an input method module library which supports various scripts and can > act as a front end for a range of input methods, including Anthy, Canna, > SKK, or T-Code/TUT-Code (for Japanese), Pinyin (for Chinese), Byeoru (for > Korean), and X-SAMPA (for the International Phonetic Alphabet). Most of its > functions are implemented in Scheme, so it's very simple and flexible. > > (I've also sorted Anthy, Canna, SKK, and T-Code/TUT-Code into > alphabetical order; mentioned uim-byeoru instead of uim-hangul; and > used the name X-SAMPA because that's the system being used as a > shorthand for IPA input. Calling it "IPA" is like calling all the > Japanese ones "Kanji".) Thank you very much. I understand what you are saying. Replaced. > >> Package: uim-gtk2.0 > > : > >> - This package contains a input method module on GTK+2.0. > >> + This package contains an IM-module for GTK+2.0. > >> +# WHAT IS THAT AND WHY SHOULD I INSTALL IT? > > > > ----------------------------------- > > This package contains an IM-module for GTK+2.0. > > You can use uim on GTK+2.0 applications. > > ----------------------------------- > > Or just > This package contains an IM-module to support the use of uim on GTK+2.0 > applications. Replaced by your one sentence. > >> Package: uim-fep > > : > >> - This package is a FEP (Front End Processor) on curses. > >> + This package provides a curses front end for UIM. > >> +# WHAT IS THAT AND WHY SHOULD I INSTALL IT? > > > > ----------------------------------- > > This package provides a curses front end for uim. > > You can use uim on console. > > ----------------------------------- > > The problem here is that all the available vocabulary for explaining > this sort of thing is ambiguous (like "front end") or technical jargon > (like "curses") or both (like "console"). I see, you are right. And I think it is "explanation". > I'm assuming that when you say "console" you don't mean that it > specifically needs to be launched in a VT login of its own (like > startx); presumably it just provides a text user interface that can be > run within an x-terminal-emulator. But it's still hard to visualise > how it works. Uim-fep runs like GNU screen... But it is not suitable explanation. A reader who does not know GNU screen does not imagine how uim-fep runs. > For instance, if I want to use this front end to type > in IPA transcriptions over an SSH connection, where should I install > uim-fep? You can install it whichever host. You run uim-fep in local host, and login to remote host. You login to remote host, and run uim-fep in remote host. Either work well. > Perhaps: > This package contains a curses Front End Processor to support the use of > uim in a text terminal. > > (Is this in fact an IM-module?) > >> Package: uim-anthy > > : > >> - This package contains Anthy plugin for uim. > >> + This package contains an Anthy plugin for UIM. > >> +# WHAT IS THAT AND WHY SHOULD I INSTALL IT? > > > > ----------------------------------- > > This package contains an Anthy plugin for uim. > > You can use Japanese input method Anthy on uim. > > ----------------------------------- > > Since it "Depends: anthy", which has its own package description, I > won't expect it to give all the details about working via hiragana. > > Perhaps: > This package contains a plugin for uim to support the use of the Japanese > input method Anthy. > Then likewise for > input method Canna. > input method SKK. > input method PRIME. > > (There's no Debian binary package called skk, but it should be clear > enough.) Replaced. > >> Package: uim-m17nlib > > : > >> - This package contains m17nlib plugin for uim. > >> + This package contains an m17nlib plugin for UIM. > >> +# WHAT IS THAT AND WHY SHOULD I INSTALL IT? > > > > ----------------------------------- > > This package contains an m17nlib plugin for uim. > > You can input text supported by m17nlib on uim. > > ----------------------------------- > > The tricky part with this one is spotting that the crucial dependency > is libm17n-0 - once I've found that (and counted the letters in > "ultilingualizatio") things get much clearer. > > Perhaps: > This package contains a plugin for uim to support the use of the > general-purpose input method M17n (for "Multilingualization"). Replaced. > (I've called it "M17n" because the library's official name is "m17n", > not "m17nlib"; because other packages such as scim-m17n use the name > "M17n" to refer to the input method; and because I'm assuming all > names of input methods get capitalised.) You are right. There are scim-m17n and ubus-m17n. But there is mlterm-im-m17nlib like uim-m17nlib. I will confer with uim packaging team about package name. > >> Package: uim-byeoru > > : > >> + This package provides UIM support for byeoru hangul. > >> +# "byeoru" means "inkstone", which is no help > >> +# WHAT IS THAT AND WHY SHOULD I INSTALL IT? > > > > ----------------------------------- > > This package provides uim support for byeoru hangul. > > You can use Korean input method byeoru on uim. > > ----------------------------------- > > There are no dependencies to chase for further information, but > googling tells me that "the Byeoru Hangul input suite covers most of > the major input methods such as 2-beol and 3-beol variants". So what > *is* the difference between this and uim-hangul? And what exactly is > an input *suite*? Sorry for my wrong impression and laziness. > Aha - a FreeBSD port in 2005 mentions that > # The 'byeoru' module (developed by Jae-hyeon Park) is far more > # superior to default hangul2/hangul3 module. And it was merged to 0.5 > # version of uim, and will serve as the default hangul input module in > # the future. > Is that future now the present? Perhaps it should be: I checked uim's NEWS file. ----------------------------------- > Overview of changes from 1.6.0 to 1.6.1 > ======================================= : > - tcode, trycode, and hangul modules are no longer enabled by > default. Use more sophisticated tutcode and byeoru modules > instead. ----------------------------------- It is the present. I will confer with team about dropping uim-hangul. > Perhaps: > This package contains a plugin for uim to support the use of the Byeoru input > module for hangul (uim's default IM for Korean). Replaced. > >> Package: uim-hangul > > : > >> + This package provides UIM support for multiple Hangul input styles: 2-beol, > >> + 3-beol, and Romaja. > >> +# whatever that is; at least it's obvious who'd use it > > > > 2-beol, 3-beol and Romaja are Hangul input styles, > > but I do not know what their's details are. > > I think it is enough description... > > It's not clear what an "input style" is, or why three of them would be > grouped together as a single "input module". Yes, you are right, it is not "explanation". > Besides, uim-byeoru > apparently supports exactly the same "styles" (in one "suite"), and is > now apparently preferred. Perhaps it shold just be: > This package contains a plugin for uim to support the use of the old Hangul > input module for Korean. Replaced. But, as mentioned above, I will confer with team about dropping it. > >> Package: uim-latin > > : > >> - This package contains Latin and Germanic languages input style for uim. > >> + This package provides UIM support for languages written in Latin scripts. > >> +# composing diacritics? Does it cover Icelandic? Rumanian? Czech? > > > > I think uim-latin supports composing diacritics > > and covers Icelandic from uim-latin's configulation. > > But it does not cover Rumanian and Czech from it, I think. > > My suspicion was that this stuff about Latin and Germanic languages > was the usual languages-versus-scripts confusion, and that uim-latin > supports more or less every Latin-derived character with a Unicode > code point. Looking at /usr/share/uim/latin.scm that seems to be true. I see. I am under languages-versus-scripts confusion. > > There is no document for uim-latin (ELatin). > > > > http://code.google.com/p/uim/wiki/WhatsUIM > > It might at least be useful to mention that it *is* "ELatin", and that > the E stands for Emacs! > > I gather that it provides composing rules for characters unique to > Icelandic, Hungarian, Vietnamese... it really seems to cover the lot. > So my first rough guess seems to have been accurate - though maybe we > could expand on it: > > This package contains a plugin for uim to support the use of the (Emacs) > Latin input method, which provides composing sequences for accented and > otherwise modified Roman-alphabet letters. Replaced. > >> Package: uim-pinyin > > : > >> - This package contains Pinyin input method(Simplified Chinese, Traditional > >> - Chinese and Unicode) for uim. > >> + This package provides UIM support for pinyin input (for Simplified or > >> + Traditional Chinese). > >> +# the Unicode reference seems like a level error > > > > uim-pinyin has three input methods: py (Simplified Chinese), > > pyunihan (Unicode) and pinyin-big5 (Traditional Chinese). > > Now I'm even more confused. How is Unicode an input method, unless > maybe you've got a keyboard with 100,000 keys? Don't all of these > work by *inputting* pinyin, and *outputting* Chinese characters in one > of three encodings? > > I can't suggest a revised version yet. Upstream says below only, there is no document... http://code.google.com/p/uim/wiki/WhatsUIM > Chinese > New Pinyin (Simplified) > Pinyin (Unicode) > Pinyin (Traditional) > >> Package: uim-tcode > > : > >> + This package provides UIM support for T-Code/TUT-Code/Try-Code input (for > >> + Japanese). > >> +# for kanji, though how it works is a mystery... > > > > Here is the unofficial T-Code information page in English. > > http://www.ki.nu/~makoto/tcode/ > > So it maps each pair of alphanumeric characters to a common kanji > character, and you use it by... memorising the whole table? Ouch. Yes, you have to memorize the table to use T-Code. But not whole, there is the relief. > Does anyone know why it's called by all these names? Can we use > "T-Code" as a cover term for all of them? T-Code is original, TUT-Code and Try-Code are derivatives. But they are generically called "T-Code". ----------------------------------- > Overview of changes from 1.6.0 to 1.6.1 > ======================================= : > - tcode, trycode, and hangul modules are no longer enabled by > default. Use more sophisticated tutcode and byeoru modules > instead. ----------------------------------- Present, upstream obsoletes T-Code and Try-Code. I will confer with team about dropping T-Code and Try-Code. > > ----------------------------------- > > This package provides uim support for T-Code/TUT-Code/Try-Code input. > > T-Code/TUT-Code/Try-Code is a kind of direct input method of Japanese > > with two strokes - see http://openlab.jp/tcode/ (Japanese). > > ----------------------------------- > > Perhaps: > This package provides uim support for T-Code/TUT-Code/Try-Code input, a > Japanese input method mapping pairs of alphanumeric codes to individual > kanji - see http://openlab.jp/tcode/ (in Japanese). > > (I don't object to the references being in Japanese as long as they're > labelled as such.) Replaced. > >> Package: uim-viqr > > : > >> - This package contains Vietnamese Quoted-Readable input style for uim. > >> + This package provides UIM support for Vietnamese Quoted-Readable input. > >> +# whatever that is; at least it's obvious who'd use it > > > > ----------------------------------- > > This package provides uim support for VIQR (Vietnamese Quoted-Readable) > > input. VIQR is a mnemonic encoding of Vietnamese characters into US ASCII > > for use on 7-bit systems - see RFC1456. > > ----------------------------------- > > Oh! So it's more like X-SAMPA (or the exact opposite of ELatin). And > this description is good just as it is (or am I just getting tired?) Thank you for your reviewing. > >> Package: uim-ipa-x-sampa > > : > >> - This package contains International Phonetic Alphabet (X-SAMPA) input style > >> - for uim. > >> + This package provides UIM support for International Phonetic Alphabet input > >> + using X-SAMPA. > >> +# well, everybody knows what that is, right? > > > > ---------------------------------- > > This package provides uim support for IPA (International Phonetic Alphabet) > > input using X-SAMPA (Extended Speech Assessment Methods Phonetic Alphabet) > > see http://www.phon.ucl.ac.uk/home/sampa/x-sampa.htm > > ----------------------------------- > > The expansion of X-SAMPA isn't very useful (it isn't obvious that it's > talking about an "Extended version of the SAMPA encoding", and anyone > who cares can look at ucl.ac.uk); more important is the fact that it's > seven-bit clean. I would suggest: > > This package provides uim support for the International Phonetic Alphabet, > using the 7-bit extended-SAMPA system - see > http://www.phon.ucl.ac.uk/home/sampa/x-sampa.htm Replaced. > >> Package: uim-yahoo-jp > > : > >> - This package contains Yahoo-JP (Web API) input style for uim. > >> - See: http://developer.yahoo.co.jp/webapi/jlp/jim/v1/conversion.html > >> + This package provides UIM support for Japanese input via the Yahoo-JP web > >> + API - see http://developer.yahoo.co.jp/webapi/jlp/jim/v1/conversion.html > >> +# seeing that page won't help if I can't read Japanese > >> +# I see no "https" here - doesn't this need a warning too? > >> +# it's completely unclear what a web Input Method Environment is > > > > There is no English page for Yahoo-JP (Web API). > > It does not support "https", so I add warning. > > > > ----------------------------------- > > This package provides uim support for Japanese input via the Yahoo-JP web > > API - see http://developer.yahoo.co.jp/webapi/jlp/jim/v1/conversion.html > > Note that all requests to the Yahoo-JP server go over the Internet > > unencrypted. > > Okay - phew! Thanks for going through all that. Thank you for your reviewing. I am deeply grateful to you. -- Regards, dai GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E
Attachment:
signature.asc
Description: Digital signature