Re: Planned changes to D-I "level 1" translation framework
On Tue, Apr 10, 2007 at 12:39:22PM +0200, Christian Perrier wrote: > I plan some changes to the D-I translation framework. > [...] > > My proposal is to split this out in 2 or more "sublevels" (the plan is > currently to use two levels): My question is, can translators still choose to translate the big PO file with everything in it instead of the split sublevel files? This would make the work easy for languages that are almost 100% translated, as the translators only need to translate several strings each time, and don't need to deal with multiple files. But I understand the benefit is quite minimal, and there are potentially quite big disadvantages for translators of different languages to work differently. Ming 2007.04.12 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Outdated dpkg translation stats on d-i l10n page
Hi Christian and everyone, My understanding is that d-i l10n stat page [1] is supposed to have the most up-to-date translations, pulling from maintainer's VCS repo if necessary. However, the stats for dpkg translation seems to be outdated. I know that simplified Chinese (zh_CN) is updated in 1.14.x uploads, but the main stat [2] still shows the old 732t88f100u stat. On the other hand, the unstable stat [3] correctly shows the new 905t13f3u stat. I think it's just the script still using an old repo path, can it be fixed? 1. http://d-i.alioth.debian.org/l10n-stats/ 2. http://d-i.alioth.debian.org/l10n-stats/level5/zh_CN.txt 3. http://d-i.alioth.debian.org/l10n-stats/level5/zh_CN.unstable.txt Thanks, Ming 2007.05.21 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kde-i18n - 3.5.7 ?
Hi Zlatko Popov, On Thu, May 31, 2007 at 02:26:27PM +, Zlatko Popov wrote: > > I see that for 10 days now KDE 3.5.7 is in "Unstable" and some of the > packages have even 3.5.7-2 version. But what about kde-i18n? It is still > 3.5.6. Any idea about the time it will appear? > > By the way, one more question: our koffice-i18n-bg file is version > 1.5.2while others are > 1.6.2, except Hebrew. Why is that? I think your are more likely to get an anwser if you ask on [EMAIL PROTECTED] list. Ming 2007.05.31 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debconf PO translations for the package exim4
I have a few comments on the template: On Wed, Jun 06, 2007 at 08:13:11AM +0200, Christian Perrier wrote: > > #. Type: boolean > #. Description > #: ../exim4-base.templates:1001 > msgid "" > "There are mails in the Exim spool directory /var/spool/exim4/input which " > "have not yet been delivered. Removing Exim will cause them to remain " > "undelivered until Exim is re-installed." > msgstr "" > > #. Type: boolean > #. Description > #: ../exim4-base.templates:2001 > msgid "" > "There are some undelivered mails in exim 3 (or exim-tls 3) spool directory /" > "var/spool/exim/input/." > msgstr "" > > #. Type: boolean > #. Description > #: ../exim4-base.templates:2001 > msgid "" > "Choosing this option will move these messages to exim4's spool (/var/spool/" > "exim4/input/) where they will be handled by exim4." > msgstr "" These three strings all mention the /var/spool/exim/input/ directory, but two with the trailing /, one without. It should be consistent. > #. Type: string > #. Description > #: ../exim4-config.templates:3001 > msgid "" > "Thus, if a mail address on the local host is [EMAIL PROTECTED], the correct > " ^^ > "value for this option would be example.org." > msgstr "" Double space. Also on a more general issue, the capitalization of the word "exim" seems to be very inconsistent in the template (there is improvement from the last version, but still not good enough IMHO). Basically there are three words/phrases: "exim", "exim4", and "exim 3". Is there a consensus on how to capitalize them? I can work on a patch if the rule is decided. Ming 2007.06.06 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debconf PO translations for the package exim4
On Thu, Jun 07, 2007 at 08:52:11AM +0200, Marc Haber wrote: > On Wed, Jun 06, 2007 at 11:26:10PM -0500, Ming Hua wrote: > > > Also on a more general issue, the capitalization of the word "exim" > > seems to be very inconsistent in the template (there is improvement from > > the last version, but still not good enough IMHO). Basically there are > > three words/phrases: "exim", "exim4", and "exim 3". Is there a > > consensus on how to capitalize them? I can work on a patch if the rule > > is decided. > > I think that there used to be a rule for capitalization given by > upstream, but I did not find that in the docs when I looked. > > I _think_ that Exim generally refers to the software package and the > system, while exim means the binary. > > In Debian, we had to extend that rule, so that the lower case name > also refers to the package itself since Debian package names are lower > case. > > Additionally, "exim" means the exim 3 packages, with "exim 3" having > the version number emphasized. The 3 is separated from the name in > "exim 3" to make clear that the exim 3 packages do not have the > version number in the package name, contrary to "exim4", where the 4 > is part of the package name. > > Is everything clear now? Yes, very clear and makes perfect sense. I read the templates again with this knowledge and things look much more consistent now. Thanks for the explanation. (For those who are interested, I asked this question because Chinese doesn't have capitalization. So I really need to understand the meaning of the capitalization in English in order to properly translate.) Ming 2007.06.07 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Standard way to mention copyright holder in PO files
On Sat, Jul 07, 2007 at 04:19:15PM +0200, Nicolas François wrote: > > I wonder if the copyright holders could not be specified in some header > fields. PO editors could update automatically the list of copyright > holders and dates. I agree with the general idea of unified format for copyright informations, but I don't think using PO header fields as below will cover all situations. > I'm thinking about something like: > > "Last-Translator: FULL NAME <[EMAIL PROTECTED]>\n" > "Language-Team: LANGUAGE <[EMAIL PROTECTED]>\n" > "Translator[0]: FULL NAME <[EMAIL PROTECTED]>, YEAR\n" > "Translator[1]: FULL NAME <[EMAIL PROTECTED]>, YEAR, YEAR\n" > "Translator[2]: FULL NAME <[EMAIL PROTECTED]>, YEAR, YEAR-YEAR\n" What about the translations whose copyright is transfered to FSF (which is acutally quite common, either due to explicit request by FSF, such as all the TP translations, or due to careless translators just using the default header generated by gettext) or (in Debian's case) SPI? What about some translators that don't want to hold copyright for his/her translation, but the team still want to credit his/her work by listing him/her as a translator? Ming 2007.07.07 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Standard way to mention copyright holder in PO files
On Sun, Jul 08, 2007 at 09:49:06AM +0200, Helge Kreutzmann wrote: > On Sat, Jul 07, 2007 at 08:54:08PM -0500, Ming Hua wrote: > > What about the translations whose copyright is transfered to FSF (which > > is acutally quite common, either due to explicit request by FSF, such as > > all the TP translations, or due to careless translators just using the > > default header generated by gettext) or (in Debian's case) SPI? > > I guess you can't code around careless users, you can just provide a > default which will be in a way desired by non-careless users. I agree it's hard to code around careless users. But that doesn't really answer my question, which is about what to do when the copyright holder and the translator is not the same person/entity. > > What about some translators that don't want to hold copyright for > > his/her translation, but the team still want to credit his/her work by > > listing him/her as a translator? > > Well, in some (many?) parts of the world you can't get rid of > copyright. For example, in Europe you don't assign your copyright to > the FSF, but rather give them a permission for unlimted use. Yes I have heard about this. Does that mean public domain is not a really valid concept in such countries? (I realize this is a legal quesiton and is probably off-topic on debian-i18n.) Ming 2007.07.08 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Standard way to mention copyright holder in PO files
On Sun, Jul 08, 2007 at 02:14:11PM +0200, Nicolas François wrote: > On Sat, Jul 07, 2007 at 08:54:08PM -0500, Ming Hua wrote: > > On Sat, Jul 07, 2007 at 04:19:15PM +0200, Nicolas François wrote: > > > > I'm thinking about something like: > > > > > > "Last-Translator: FULL NAME <[EMAIL PROTECTED]>\n" > > > "Language-Team: LANGUAGE <[EMAIL PROTECTED]>\n" > > > "Translator[0]: FULL NAME <[EMAIL PROTECTED]>, YEAR\n" > > > "Translator[1]: FULL NAME <[EMAIL PROTECTED]>, YEAR, YEAR\n" > > > "Translator[2]: FULL NAME <[EMAIL PROTECTED]>, YEAR, YEAR-YEAR\n" > > > > What about the translations whose copyright is transfered to FSF (which > > is acutally quite common, either due to explicit request by FSF, such as > > all the TP translations, or due to careless translators just using the > > default header generated by gettext) or (in Debian's case) SPI? > > > > What about some translators that don't want to hold copyright for > > his/her translation, but the team still want to credit his/her work by > > listing him/her as a translator? > > We could differentiate > Copyright (C) FULL NAME <[EMAIL PROTECTED]>, YEAR > and > FULL NAME <[EMAIL PROTECTED]>, YEAR What do you think of using "Copyright-Holder" field? IMHO, if we decide to start using fields to record the copyright/license field, we'd better try putting all necessary information in the fields, instead of having a "need to check both file header and information fields" situation. That would unavoidably lead to controversial information. I also like the idea of "License" field. Ming 2007.07.08 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DDTP: Please remove pl_PL and merge it with pl
On Thu, Jul 12, 2007 at 08:10:19PM +0200, Michael Bramer wrote: > > ok, we have now still this problems: Since there seems to be an effort to clean up language code for DDTP, may I ask the admins to get rid of zh (Chinese)? It currently has 21 active translations from 22 translations. Chinese must be separated as (at least) zh_CN and zh_TW, as although they are the same language, they use different scripts. I have no idea what script the current zh translations are, is there an easy way to review them? I'll do that and put them into correct category. Also please make sure DDTP/DDTSS do not accept ambiguous zh translations anymore. Thanks, Ming 2007.07.14 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: desktop and/or menu files localization
On Sat, Jul 14, 2007 at 07:54:58AM +0200, Christian Perrier wrote: > > Quoting Josselin Mouette ([EMAIL PROTECTED]): > > Le vendredi 13 juillet 2007 à 17:30 -0400, Joey Hess a écrit : > > > There are probably enhancements that would let it create _better_ > > > .desktop files. For example, ones with translations.. > > > > Ah, right. I forgot translations. Another good reason to drop the Debian > > menu system. > > Speaking about desktop files l10n, the current way to > translate them does not seem to scale very well to me. > > From what I see in the dozens of .desktop files I have on my own > system, I see "Field[code]" fields for translations of "Field". IIUC, these fields are (can be) automatically filled by intltool, using the translations in PO files. So for translators the whole process is transparent, they only need to deal with PO files. > I suppose that big projects like KDE and GNOME have setup their own > l10n infrastructure to localize these, but allowing the same to happen > with other .desktop files would be an interesting enhancement. The tool is there, it's just up to the individual software writer if he/she wants to set up the infrastructure for translating desktop file. [I am not subscribed to debian-devel, please cc: me if debian-i18n is not crossposted.] Ming 2007.07.14 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DDTP: Please remove pl_PL and merge it with pl
On Sat, Jul 14, 2007 at 01:54:20PM +0200, Jens Seidel wrote: > On Sat, Jul 14, 2007 at 03:01:13AM -0500, Ming Hua wrote: > > Chinese must be separated as (at least) zh_CN and zh_TW, as although > > they are the same language, they use different scripts. I have no idea > > what script the current zh translations are, is there an easy way to > > review them? I'll do that and put them into correct category. > > > > Also please make sure DDTP/DDTSS do not accept ambiguous zh translations > > anymore. > > Can you please check http://ddtp.debian.net/debian/dists/sid/main/i18n/ > and merge zh translation manually with either zh_CN or zh_TW (via mail > interface), we cannot do this without knowledge of the language and > don't wont to drop all 22 translations. Of course, I didn't suggest to drop them. I've now downloaded the Translation-zh file and found out that they are all simplified (zh_CN) translations, so should be merged into zh_CN. I'll do this via email interface in the following days (I need to learn using DDTP), and it's safe to turn off accepting zh translations now. > But are you really sure that it is not possible to convert a common > Chinese translation into zh_CN AND zh_TW? I'm so glad that you brought this up again. I was reading the thread "Re: DDTP - please activate support for pt" yesterday and found you've mentioned Chinese translation in that thread. I wanted to reply, only to realize your mail was in February. > Please note that this is done > by the Debian website, there is only a single translation but multiple > output encodings!? I know for website translation, zh_CN and zh_TW pages are generated from a single source file. However, it's not exactly a single translation, the source wml file supports the grammar "[CN:foo][HKTW:bar]", so that the generated page will use "foo" for zh_CN html and "bar" for zh_TW html. It's quite a maintenance hassle. Also, the difference between scripts is not only encoding (both zh_CN and zh_TW translations can, and prefer to, use UTF-8 nowadays, at least in the open source world). Encoding is not even the main part of the conversion. The website's wml source is usually in zh_CN or zh_TW depending on the preference of the main translator (as wml doesn't support UTF-8, IIRC), then the conversion to the other script is done by a third-party program (iconv is not really good enough for this task). I think currently the tools in zh-autoconvert package are used. The result, if not touched up by a translator of the other script (by adding more [zh:foo][HKTW:bar] alternative tags), will read awkward most of the time, and sometime even confusing. So you see, generating both zh_CN and zh_TW translations from a single source is not really ideal. IMHO the maintenance hassle, as well as the suboptimal results, is one of the reason that Chinese website translations have been stagnant these years. > Could someone please explain this? Why waste time for two > encodings/scripts if one is sufficient? So in short, it's not an encoding issue. I only know English and Chinese, but I suspect the difference is probably on par with nn (Norwegian Nynorsk) and nb (Norwegian Bokmål). One translation is not possible. One source is possible, but inconvenient and suboptimal. Both zh_CN translators and zh_TW ones (though I can't speak for them) would prefer separate translations. Hope this makes things a bit more clear. Ming 2007.07.14 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DDTP: Please remove pl_PL and merge it with pl
On Sun, Jul 15, 2007 at 12:24:14PM +0200, Jens Seidel wrote: > On Sat, Jul 14, 2007 at 08:17:47PM -0500, Ming Hua wrote: > > > > Of course, I didn't suggest to drop them. I've now downloaded the > > Translation-zh file and found out that they are all simplified (zh_CN) > > translations, so should be merged into zh_CN. I'll do this via email > > interface in the following days (I need to learn using DDTP), and it's > > safe to turn off accepting zh translations now. > > It's not difficult but could nevertheless require a few hours of work: > Obtain the current zh_CN translation via a subject line > GET zh_CN.UTF-8 > Wait for the mail and decide wether the zh_CN or zh translation should > be used (or merge both). Copy the translation into the proper mail > attachment part and send it back to [EMAIL PROTECTED] That's all. > (You can send multiple messages back at once, but test with a single one > first.) Thanks for the note. I am working on this. > Thanks for the explanation. Nevertheless using an already translated > description into zh_TW as default template for zh_CN would be useful, > right? Same for pt and pt_BR. It would be useful, yes, but probably not for every translator. I personally like to compare with zh_TW translations when working on zh_CN ones, but I know some translators don't like the other script. The translation for zh_TW can't be used as is for zh_CN anyway, since the scripts are still different even both are using UTF-8, and conversion is required. As there is always political tension in such issues, I suggest not to implement sending zh_TW translation as the default template for zh_CN without discussion among zh_CN translators. I am not doing DDTP translation myself so I would rather not be involved. The Chinese DDTP translations doesn't seem very active now anyway. > Michael, could you implement this? I also suggest to assume that the > user always requests UTF-8 encodings if he didn't explicitely specified > the encoding. So please always send "Description-.:" > messages, where defaults to UTF-8. Thanks. Ming 2007.07.15 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: [i18n] Input Method and Fonts improvements for Gutsy
(Dropping pkg-fonts-devel list, as they are not likely interested in input method discussions. Adding ubuntu-devel list.) On Tue, Aug 07, 2007 at 09:05:20AM +0200, Christian Perrier wrote: > Quoting Daniel Glassey ([EMAIL PROTECTED]): > > Hi, > > I think it would be good to discuss this with Debian folks at well to > > share their expertise and I think these issues should be addressed for > > lenny as well. > > And, given that this highly involves packages beings installed by > default, this should be discussed with the D-I team as such default > installations should be handled by tasksel in Debian. > > (please note that Ubuntu does not use tasksel and, therefore, > solutions suitable for Ubuntu will, there, not be suitable for Debian > and vice-versa) Since Debian doesn't have the constraint of the main/universe separation, Debian can use a very different approach than Ubuntu's. And AFAIK, on CJK front, etch already has a rather good input method support in default desktop task installation. > So, original message by Arne Goetje, forwarded by Daniel Glassey: > > > So, for making SCIM the system wide default, the following should be > > done on the Live CD and in the default installation: > > 1. install and configure scim and its modules > > I think that this should be done by default when installs are done for > non european languages, at least those that are supported by SCIM > (CJK? Indic languages? Other Asian languages? Cyrillic?) For desktop tasks, yes. For others, probably not, since scim pulls in the whole GTK+ stack. Most other input method packages at least pull in a lot of X stuff. > > 2. install im-switch > > Ditto Depends on whether the specific input method package has im-switch support or not. > > 2. SCIM modules: > > The default installed scim module packages are: > > * scim-modules-table > > * scim-tables-additional (Russian and Indic IMs) > > Could go in the -desktop tasks for Indic and Cyrillic langs I heard that the Russian input method in there is not really useful for native speakers. A lot of Indic speakers probably prefer scim-m17n package instead. > > I highly recommend, that we put the following packages and their > > dependencies into the Live CD and the default installation to make it > > become more useful: All the following are based on current tasksel SVN trunk, I don't have time to check etch. But it's probably quite similar -- I don't remember big changes to existent tasks since etch release. > > * scim-anthy or scim-prime: Japanese input methods, scim-prime is a > > dictionary based IM, which has a great advantage over anthy. Although > > both are widely used in Japan. > > Ditto for japanese-desktop Japanese-desktop depends on uim, but not im-switch. I remember uim has im-switch support. They probably want to consider that. > > * scim-chewing: Traditional Chinese phonetic IM, widely used in Taiwan > > ditto for chinese-t-desktop (already done, indeed) Yes, and it depends on im-switch as well. > > * scim-pinyin: Simplified and Traditional Chinese Pinyin IM, widely > > used in China and by foreigners in Taiwan. ;) > > ditto for chinese-t-desktop and chinese-s-desktop Native traditional Chinese speakers hardly use Pinyin, so I am not sure it's justified. Chinese-s-desktop already depends on scim-pinyin and im-switch. > > * scim-hangul: As the name says it - Korean. > > ditto for korean-desktop Korean-desktop depends on imhangul and nagi for input method. > > * scim-tables-zh: additional table based IMs for Simplified and > > Traditional Chinese, many of them are popular in China, Hong Kong and > > Taiwan. > > ditto for chinese-t-desktop and chinese-s-desktop Already done. > > * scim-thai: well, Thai. :) > > ditto for thai-desktop Thai-desktop depends on gtk-im-libthai for input method. > > * scim-m17n: bridge to the m17n library, which adds a lot of additional > > IMs, including Latin based ones for the European languages with > > diacritics. (not everyone likes to fiddle with XKB settings. ;) ) > > hmmm, seeing this makes me think that, after all, scim could be > installed by default on all desktop installs, and scim-m17n added to > *-desktop tasks for Latin-based languages. Many languages prefer other input methods. Actually now that I'm thinking about it, I am not even sure SCIM has more than 50% user base for any language. Some Indic language perhaps, as SCIM may be the only available one. > > The following packages may NOT be installed: > > * scim-uim: BROKEN, will trash the SCIM setup tool. Don't install it. > > * scim-chinese: old version of scim-pinyin, not compatible with the > > current scim package; breaks dependency handling. Just FYI: I replied to this in a mail to ubuntu-devel list. In summary: at least in Debian, these are not true at all. Both scim-uim and scim-chinese are perfectly installable and usable in etch as well as unstable. Ming, Debian maintainer of scim 2007.08.10 -- To UNSUBSCR
Re: Fwd: [i18n] Input Method and Fonts improvements for Gutsy
(Again dropping pkg-fonts-devel list.) On Tue, Aug 07, 2007 at 02:01:58PM +0200, Christian Perrier wrote: > > > 3. run as root: > > > im-switch -s scim > > > After a relogin, the user can toggle SCIM on/off by pressing CRTL+SPACE. > > > > > >> "im-switch -s scim" should be done once on the installed system, or at > > >> every boot? > > > > only once at install time. And only if you want to use SCIM as default > > IM application... > > Hmmm, OK, then that could fit in the localechooser finish-install > script. Something like: > > "check whether scim is installed on the installed system and, if so, > run 'im-switch -s scim'" Not really necessary. Scim's im-switch setting already makes scim default (which is what "im-switch -s scim" do) for Chinese, Japanese, and Korean locales in etch. If some language decides that SCIM is good as the default input method, they can just ask scim package to raise im-switch setting priority for their locale. Ubuntu needs to manually set im-switch default more often because their language-support packages are real (meta-)packages, and frequently installed in systems with other locales. Ming 2007.08.10 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: [i18n] Input Method and Fonts improvements for Gutsy
On Sat, Aug 11, 2007 at 11:26:08AM +0100, Matt Zimmerman wrote: > On Fri, Aug 10, 2007 at 10:33:09PM -0500, Ming Hua wrote: > > On Tue, Aug 07, 2007 at 09:05:20AM +0200, Christian Perrier wrote: > > > Quoting Daniel Glassey ([EMAIL PROTECTED]): > > > > Hi, > > > > I think it would be good to discuss this with Debian folks at well to > > > > share their expertise and I think these issues should be addressed for > > > > lenny as well. > > > > > > And, given that this highly involves packages beings installed by > > > default, this should be discussed with the D-I team as such default > > > installations should be handled by tasksel in Debian. > > > > > > (please note that Ubuntu does not use tasksel and, therefore, > > > solutions suitable for Ubuntu will, there, not be suitable for Debian > > > and vice-versa) > > > > Since Debian doesn't have the constraint of the main/universe > > separation, Debian can use a very different approach than Ubuntu's. And > > AFAIK, on CJK front, etch already has a rather good input method support > > in default desktop task installation. > > Ubuntu does in fact use tasks, though they aren't presented to the user by > default in the installer, as in Debian. I'm curious why you feel that the > distinction between main and universe is an issue here. Oh, I didn't know that Ubuntu also uses tasks. But I think most Ubuntu installation use language-support packages instead of tasks to install input methods anyway. My understanding (which may be wrong) is that all language-support packages in Ubuntu are main packages, and therefore all their dependencies are also main packages. I think this also makes Ubuntu developers want to minimize the number/size of supported (does supported seed equal to main?) packages, leading to the decision of using SCIM for input method support for all languages. However, as I wrote, it may not be optimal from a user's point of view. In Debian, however, tasks can depend on (include? -- since missing dependency in tasks in not fatal) input method packages as long as they are in the archive, without going through the "main inclusion process" as they need to do in Ubuntu. So many tasks include more than one input method packages, and quite some of them don't use scim at all. As im-switch is essentially an alternative system, users can then use im-switch to choose the input method he/she prefers. I doubt Ubuntu will be willing to support multiple input method packages. SCIM doesn't have the best support for all languages, its biggest advantage is multi-language support. SCIM also has its own shortcomings, the most infamous one being causing crash in GTK+ applications linked to libstdc++5 [1,2,3], which means firefox from mozilla.org, Adobe acroread, ATi proprietary video driver, etc. For users only using one language (or English and another language only), they have many reasons to prefer another input method. Debian's task system can support this easily. Ubuntu's language-support package system doesn't seem to be supporting this now, and I don't feel it will support this unless there are significant changes in the way input method packages are developed/tested and in the main inclusion process. 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=323216 2. https://bugs.launchpad.net/ubuntu/+source/scim/+bug/2246 3. https://bugs.launchpad.net/ubuntu/+source/scim/+bug/80551 Ming 2007.08.11 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: [i18n] Input Method and Fonts improvements for Gutsy
On Sat, Aug 11, 2007 at 01:49:34PM +0800, Arne Goetje wrote: > Ming Hua wrote: The part of Christian's quote you trimmed: "Hmmm, OK, then that could fit in the localechooser finish-install script. Something like:" > >> "check whether scim is installed on the installed system and, if so, > >> run 'im-switch -s scim'" > > > > Not really necessary. Scim's im-switch setting already makes scim > > default (which is what "im-switch -s scim" do) for Chinese, Japanese, > > and Korean locales in etch. If some language decides that SCIM is good > > as the default input method, they can just ask scim package to raise > > im-switch setting priority for their locale. > > > Ubuntu needs to manually set im-switch default more often because their > > language-support packages are real (meta-)packages, and frequently > > installed in systems with other locales. > > I was referring to the Live CD, which uses US-English as default locale. Right, but I was replying to Christian's comment about adding something to localechooser to do such a thing, and I feel that unnecessary. > I found out in the meantime, that the Live CD uses gtk-immodule and that > SCIM is available via the context menu under the Input Method entry. > However, I think that the average newbie won't be able to find that on > his/her own. So I was suggesting to use im-switch and the XIM method as > default. But as XIM has the problem with the need of predefined > /SupportUnicodeLocale setting and users probably won't install any 3rd > party application on the Live CD which has trouble with the > GTK_IM_Module=scim setting, it should be enough to set the environment > variable GTK_IM_Module=scim whenever Complex Input Method support is > activated in the Language Switcher. I agree it's tricky to support input method for both Live CD and the installed system, and need its own discussion. But it's probably not what Christian proposed, by running im-switch in localechooser (does Ubuntu Live CD install use localechooser at all?). Ming 2007.08.11 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: [i18n] Input Method and Fonts improvements for Gutsy
On Mon, Aug 13, 2007 at 01:31:37PM +0100, Matt Zimmerman wrote: > On Sat, Aug 11, 2007 at 09:10:57AM -0500, Ming Hua wrote: > > > SCIM doesn't have the best support for all languages, its biggest > > advantage is multi-language support. SCIM also has its own shortcomings, > > the most infamous one being causing crash in GTK+ applications linked to > > libstdc++5 [1,2,3], which means firefox from mozilla.org, Adobe acroread, > > ATi proprietary video driver, etc. > > This sounds more like a bug than a shortcoming; can it not be fixed? It > sounds like a dynamic linking issue, and there are folks around who know > that part of the stack much better than I do. Yes, it is a bug, already reported in Debian [1] and Ubuntu [2]. From what I have understood, the really culprit is GCC, and to fix it would need an ABI change in libstdc++, so we have to wait for libstdc++7 to have it fixed. I don't claim I get all the facts right though, the bug reports have enough pointers for people who are interested in this problem. 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=323216 2. https://bugs.launchpad.net/ubuntu/+source/scim/+bug/2246 Ming 2007.08.26 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [D-I] Number of strings in D-I level 1 bumped to 1683
On Sun, Sep 23, 2007 at 08:45:10PM +0200, Helge Kreutzmann wrote: > On Sun, Sep 23, 2007 at 08:24:16PM +0200, Christian Perrier wrote: > > > > Thanks to the work of Frans, comments are now also very clear as they > > explain which country the time zones belong to, allowing translators > > to seek for the correct information to find out how these various > > strange places names have to be translated in their language. > > Is this related to your earlier call for translations for the package > tzdata 2007e-7? I don't think there is any actual content change. It's just splitting the strings. I remember the original calls for translation sent by Christian already included the timezone name translations merged from d-i translation. So this change shouldn't affect tzdata translation's status. It makes reusing/merging translations between d-i and tzdata easier, though. > If yes, where does the current version reside? What are you referring to? D-i translations are kept in SVN repo on svn.debian.org. Ming 2007.09.23 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [D-I] Number of strings in D-I level 1 bumped to 1683
On Mon, Sep 24, 2007 at 06:18:29AM +0200, Christian Perrier wrote: > > However, at this very moment, new timezones would have to be > translated in both D-I's tzsetup and tzdata. There is a similar situation for the language names in tasksel and iso-codes. > Of course, automating this would be an interesting goal to have..:-) I don't think automation is really necessary. Just collaboration between the two translators (or inside the team) should be good enough. Ming 2007.09.24 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: UTF-8 manual pages
On Wed, Oct 17, 2007 at 06:03:34PM +0930, Clytie Siddall wrote: > > Another note about Colin's original, and very well-thought-out post: > I think Yelp _does_ support UTF-8. I'm pretty sure I tested my pilot > Vietnamese manpage in it (as well as groff-utf8) a year or two back. Actually I was thinking about this a few days ago too. I just tried for simplified Chinese (zh_CN): On up-to-date unstable with yelp 2.20.0-1 and man-db 2.5.0-3: The one-line description (in the search result page) is displayed correctly. The manpage itself is not, I see Latin characters as if the Chinese is literally parsed as ISO-8859-*. On a not-so-up-to-date unstable with yelp 2.18.1-1 and man-db 2.4.4-4: The one-line description is in English. The manpage itself is broken too, but in a different way -- I see Chinese (and some Japanese) characters, but they are not what they are supposed to be, but just some nonsense. Something is wrong in the decoding-encoding process. I am testing in a en_US.UTF-8 locale, use "LANG=zh_CN.UTF-8 yelp" to start yelp. The man page used is chsh(1), shipped in passwd package itself, and uses GB2312/GBK encoding. If I use "LANG=zh_CN.GBK yelp" instead, everything is the same except that the one-line description in up-to-date unstable is broken too (in yet a third way). Just a data point for anyone who is interested in more digging. Ming 2007.10.17 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debconf PO translations for the package flex
On Tue, Oct 30, 2007 at 07:38:05AM +0100, Christian Perrier wrote: > > The debian-l10n-english team has reviewed the debconf templates for > flex. This opens an opportunity for new translations to be sent > for that package. > [...] > > msgid "" > "The behavior of Flex has undergone a major change since version 2.5.4a. Flex > " > "scanners are now reentrant: they can have multiple scanners in the same " > "program with differing sets of defaults, and they play nicer with modern C " > "and C++ compilers. The flipside is that Flex no longer conforms to the POSIX > " > "lex behavior, and the scanners require conforming implementations when Flex " > "is used in ANSI C mode. The package flex-old provides the older behavior." > msgstr "" Since even sarge has flex 2.5.31, does this template really have a chance of being displayed? (Just a lazy question, I haven't checked the maintainer script.) Ming 2007.11.07 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xlibs-data: Help needed with CJK issues
> Denis Barbier wrote: > >In your comment, you tell that unifont can be used for these languages. > >This package is part of Chinese tasks (from tasksel), but not Japanese > >ones. The latter contain several other font packages. On Fri, Apr 22, 2005 at 06:59:10PM +0800, Tetralet wrote: > The "unifont" package will be installed by default in Sarge. No it won't. As Denis has said, unifont is installed by Chinese desktop task. Although d-i uses jfbterm and unifont, they are not INSTALLED by default for a sarge system. At least not on my sarge box installed with English d-i. There is one thing to consider, though. Japanese environment (not the desktop) task depends on jfbterm, and jfbterm depends on (unifont | xfont-base). The Japanese desktop task doesn't depends on jfbterm or unifont, however. So there is still good chances for a Japanese desktop to have unifont installed, isn't there? (I must admit I've never tested Japanese d-i, so this is just speculation.) Ming 2005.04.22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [D-I] Hints for timezone names translations in D-I
On Thu, Jul 28, 2005 at 07:29:19PM +0200, Javier Fernández-Sanguino Peña wrote: > > - why are they so many timezones for China? Reading the Wikipedia > (which has been useful to understand the timezones BTW) it looks like > China has a single timezone for all the country... Good question. We Chinese users on #debian-zh channel were wondering about the same thing a few days ago. I'm not sure, but from what I heard China used to have four different timezones (mainland China does span across 4-5 time zones after all). There were also other changes during the past years, for example, we used daylight saving time in the 1980s, but abandoned the idea a few years later. Right now, it seems we are using one timezone everywhere. I suppose these timezones are defined in glibc. If there is a possibility to fix this (at least in Debian packages), I would volunteer to collect the official data, at write a summary. I'm afraid I can't write any code myself though. Is debian-i18n a good place to discuss this, or should I write somewhere else? Thanks, Ming 2005.07.28 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [D-I] Hints for timezone names translations in D-I
> Ming Hua wrote: > > I'm not sure, but from what I heard China used to have four different > > timezones (mainland China does span across 4-5 time zones after all). > > There were also other changes during the past years, for example, we > > used daylight saving time in the 1980s, but abandoned the idea a few > > years later. Right now, it seems we are using one timezone everywhere. > On Thu, Jul 28, 2005 at 10:09:16PM -0400, Joey Hess wrote: > I seem to have missed China when doing timezone minimization. Fixed. Thanks for fixing this. I'll do some testing once beta is out. Ming 2005.07.29 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A few typos in debian-installer (Was: Re: [D-I] Variable subsitution (level2))
On Sun, Sep 25, 2005 at 12:40:34AM +0200, Jens Seidel wrote:
> attached you will find a few typo corrections for the following d-i
> files:
[snipped]
> M packages/po/zh_TW.po
I am not in the zh_TW team (I am in the zh_CN one), but I read zh_TW
just fine. I see that Christian has already checked in the patch
(pasted at end of this mail), I'm just confirming that they are indeed
simple English typos and the patch is good.
Ming
2005.09.25
Index: packages/po/zh_TW.po
===
--- packages/po/zh_TW.po(Revision 30881)
+++ packages/po/zh_TW.po(Arbeitskopie)
@@ -5511,7 +5511,7 @@
"${BOOT} and ${ROOT} passed as a kernel argument."
msgstr ""
"您將需要手動由 ${BOOT} 分割區的 ${KERNEL} Kernel 開機，並加上 ${ROOT} 以做為 "
-"Krenel 的參數。"
+"Kernel 的參數。"
#. Type: boolean
#. Description
@@ -6231,7 +6231,7 @@
#. Description
#: ../quik-installer.templates:88
msgid "Failed to resolve initrd symlink"
-msgstr "無法解析 intrd 的符號連結"
+msgstr "無法解析 initrd 的符號連結"
#. Type: error
#. Description
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question on checking translations
On Wed, Oct 12, 2005 at 07:08:35AM +0200, Christian Perrier wrote: > Quoting Sunjae Park ([EMAIL PROTECTED]): > > I'm almost done translating the packages/po/ko.po file. But there > > are a few things that I would like to check out. There are a few > > strings that are marked fuzzy, and frankly I am not confident enough > > to 'unfuzzy' them until I can see what content the strings are used > > in. Is there any advice in this? > > "podebconf-display-po file.po" can help you in some cases This > command comes along with the po-debconf package. But I suppose Sunjae Park is talking about the master po file that aggregates all the messages. To use podebconf-display-po, he has to get the individual po files at packages//debian/po/ko.po, doesn't he? I usually just look at the debconf template at packages//debian/*.template, to get some idea about the context. Ming 2005.10.12 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Doubt with "&" markers (was: Re: Call for translations: desktop-profiles)
On Wed, Oct 26, 2005 at 12:43:39AM -0200, Felipe Augusto van de Wiel (faw) wrote: > > I have a doubt, I'm translating the profile-manager.pot to Brazilian > Portuguese and there are some situation like this: > > &kind matches > > The translation is > > tipo corresponde > > My idea is to use the same letters for the "&" markers, but in that > case I could use it, what is the correct procedure in that case? Chinese has such kind of issues everywhere, we use the format like tipo correspode (&k) Ming 2005.10.25 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
The environment variable $LANGUAGE
I have a question to the list: What documentation should I read to understand the environment variable $LANGUAGE, and it's relationship with the ordinary locale variables ($LANG, $LC_*, and $LC_ALL)? There was a thread on debian-chinese-gb list [1], about a problem that the user can't get a Chinese GNOME environment from startx no matter how he sets the locale. It turns out the problem is the "export LANGUAGE="en_US:en_GB:en" line in /etc/environment, changing it to "zh_CN:en_US:en" solves the problem. This line is set by debian-installer when install in US English. [2] My previous impression has been that $LANGUAGE is just an auxiliary variable, helping to choose the second desired language if the first is not available. However Christian has pointed to me that's not the case, and the application can user $LANGUAGE "however as they want". It seems in GNOME, $LANGUAGE overrides $LANG and $LC_MESSAGES settings. So I'd like to know more about the usage of $LANGUAGE, but I can't find good documentations. Can anyone on the list provide some pointers (or give some opinions)? 1. (in Chinese) http://www.mail-archive.com/debian-chinese-gb@lists.debian.org/msg11068.html 2. People would say "then don't install in English, install in Chinese"! But the problem is that d-i doesn't install a framebuffer-enabled terminal (like jfbterm used in 1st stage) for Chinese install. So the user will get garbled characters in the 2nd stage of installation (the part running base-config), so most Chinese users choose to install in English instead. Thanks in advance, Ming 2005.11.03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The environment variable $LANGUAGE
> > framebuffer-enabled terminal (like jfbterm used in 1st stage) for > > Chinese install. So the user will get garbled characters in the 2nd > > stage of installation (the part running base-config), so most Chinese > > users choose to install in English instead. > On Fri, Nov 04, 2005 at 07:26:37AM +0100, Christian Perrier wrote: > *That* is not true. 2nd stage runs fine with CJK languages because > base-config is run under jfbterm. If it does not run fine, this is a > bug. I stand corrected. Actually I must confess that I've never done an installation in Chinese myself - I've did some test to see if the Chinese characters display correctly, but never finished the install. For my own system I always install in English (and use an English locale, for that matter). I just heard a lot of Chinese users complain that there would be garbled characters "after reboot". So I thought it was the 2nd stage of installation. Sorry for the misleading message. > However, the end system will display garbage *later*, if localized in > CJK languages (or Arabic, Hebrew...) because jfbterm cannot be run as > a login program. There's a discussion about this in localechooser bug > log and no real possible solution. I agree that is quite a hard problem to solve. Ming 2005.11.05 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The environment variable $LANGUAGE
On Fri, Nov 04, 2005 at 08:33:44AM +0100, Miroslav Kure wrote: > On Thu, Nov 03, 2005 at 07:02:01PM -0600, Ming Hua wrote: > > I have a question to the list: What documentation should I read to > > understand the environment variable $LANGUAGE, > > info libc -> Message Translation -> The Uniform approach -> > Message catalogs with gettext -> Using gettextized software > > > and it's relationship with the ordinary locale variables ($LANG, > > $LC_*, and $LC_ALL)? > > If set, LANGUAGE has higher priority than LANG, LC_MESSAGES and even > LC_ALL variable, but character *encoding* is still taken from LC_CTYPE. > [example snipped] > > So the best usage would be to use only locales with the same encoding, > preferably UTF-8. Thanks for the pointer and explanations, it's very helpful. My main problem is that I use en_US.UTF-8 locale and prefer English interfaces. However occasionally I need to run programs in LC_MESSAGES=zh_CN to see the translation results (I assume LC_MESSAGES=zh_CN.UTF-8 has the same effect, as the encoding part doesn't matter). I think setting LANGUAGE to empty serves me best. :-) Ming 2005.11.05 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Translation for aptitude
Hi, I have two issues about translation for aptitude. I figure I'll ask here first, and if most translators agree with me, I'll file bugs against aptitude. They are mostly related to CJK languages, but I suppose many other non-Latin languages would be interested as well, especially issue #1. 1. The following two entries REALLY need comments for translators: #: src/ui.cc:2690 src/vscreen/vscreen.cc:724 msgid "yes_key" msgstr "" #: src/ui.cc:2691 src/vscreen/vscreen.cc:725 msgid "no_key" msgstr "" These are the shortcut keys you need to press when answering a Yes/No question. While the aptitude developers care i18n enough to give the possibility to localize this shortcut key, without a comment translators won't know they are supposed to translate them to a single key that stands for yes/no (in English, they'll be "y" and "n"). These shortcut keys are used quite often, for example, in the dialog of quitting aptitude. This is also the cause of bug #338056. The zh_TW translation is just literally "the yes key", and it seems aptitude just take the first character of the translated string. I've done a grep in the po/ directory, and fewer that half of the languages have one-character translations (although many others just have it untranslated, so that should give y/n). 2. Can the developers somehow separate the following strings? #: src/cmdline/cmdline_prompt.cc:413 src/vscreen/vs_util.cc:177 #: src/vscreen/vs_util.cc:215 msgid "Yes" msgstr "" #: src/cmdline/cmdline_prompt.cc:413 src/vscreen/vs_util.cc:178 #: src/vscreen/vs_util.cc:216 msgid "No" msgstr "" These are actually three Yes/No pairs. The two for src/vscreen/vs_util.cc:178 and src/vscreen/vs_util.cc:216 are strings shown to users, and we zh_CN translators want to translate them. On the other hand, the pair for src/cmdline/cmdline_prompt.cc:413 is both for display AND to match the user's input. It goes like Do you want to ignore this warning and proceed anyway? To continue, enter "Yes"; to abort, enter "No": and the user need to type in the string that match the Yes/No translation here. And a Chinese user recently complained in our mailing list that it would make much more sense for the user to just type the English word "Yes" or "No" to answer, instead of having to type Chinese (or worse, rely on copy and paste as inputting Chinese is harder than displaying Chinese), and most of us agree. The problem is that if we change this translation, the two other Yes/No pairs got displayed in the ncurses user interface will go back to English as well, and we want to avoid that. So in brief the request is to separate the strings that are display-only and that are both for display and input. For Chinese, we translators want to show localize messages but generally try to avoid enforcing the user to input Chinese, as it sometimes causes big inconvenience. So what does the fellow translators think? Ming 2005.11.08 signature.asc Description: Digital signature
Re: [d-i] Ubuntu-related strings in apt-setup
On Mon, Nov 14, 2005 at 09:33:24AM +, Colin Watson wrote: > They're not too different from the normal strings, and I made > sure to put translator comments in the additional templates to say that > they're only used in a derived distribution. The comments now looks like this: --- 8< --- #. Type: boolean #. Description #. This template is used by the Ubuntu version of d-i. #: ../apt-mirror-setup.templates-ubuntu:5 msgid "Use restricted software?" msgstr "" #. Type: boolean #. Description #: ../apt-mirror-setup.templates-ubuntu:5 msgid "" "Some non-free software is available in packaged form. Though this software " "is not a part of the main distribution, standard package management tools " "can be used to install it. This software has varying licenses which may " "prevent you from using, modifying, or sharing it." msgstr "" --- >8 --- It seems the comments are only added to the first string among the ones in the same line of the template, and not the following strings. I think it may cause some wrong impression (altough it's easy to tell by just looking at the .templates-ubuntu suffix). So if this is hard to fix in gettext, maybe you can change the comments to something like "The following two strings are used..."? Thanks, Ming 2005.11.14 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Short guide on Plural-Forms
Hi fellow translators, I never understood this Plural-Forms thing about gettext (mainly because we Chinese don't have any plural form whatsoever :-). But I still see such things in PO files, and I've never dare to touch them, fearing that I'll get the format wrong. The d-i i18n documentation [1] (by the way, translators should really read it, even if you don't work for d-i) isn't really helpful either. So today I'm very happy to see autopackage project providing a guide [2] on this issue, and it is very helpful to me. I'd like to share the information here, so that anyone with the same question can benefit. 1. http://people.debian.org/~bubulle/d-i/i18n-doc/index.html 2. http://www.autopackage.org/docs/i18n/#translating_plural Ming 2005.11.14 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#338056: Translation for aptitude
On Fri, Nov 18, 2005 at 05:03:01PM +0100, Ruben Porras wrote: > Am Mittwoch, den 09.11.2005, 06:46 +0100 schrieb Christian Perrier: > > > These are the shortcut keys you need to press when answering a Yes/No > > > question. While the aptitude developers care i18n enough to give the > > > possibility to localize this shortcut key, without a comment translators > > > won't know they are supposed to translate them to a single key that > > > stands for yes/no (in English, they'll be "y" and "n"). These shortcut > > > keys are used quite often, for example, in the dialog of quitting > > > aptitude. > > Well, what i'm wondering is where has gone the file README.i18n from > aptitude's sources. It was pretty illustrating: Just read this file, it's indeed quite illustrating. However considering that many translators get the aptitude POT file from the d-i i18n web page, chances are that they've never seen this README.i18n file (myself included). Maybe adding a pointer in the POT file (maybe existing PO files as well) would be helpful? Ming 2005.11.19 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Quotation marks - commit planned for language css in webwml
On Mon, Dec 19, 2005 at 10:45:10PM +0100, Jutta Wrage wrote: > > Please have a look at > > URL http://www.witch.westfalen.de/csstest/quotes/quotes.html > (css with unicode numbers of quotation marks is include in the file) > > and > > URL http://www.witch.westfalen.de/csstest/quotes/quotes-large.html > > For the following languages I have no feedback (or missed it, sorry) > and will commit the first alternative, if there is more than one: > [snipped] > Chinese simplified (zh-cn) > Chinese hongkong (?) (zh-hk) > Chinese traditional (zh-tw) [snipped] I'm from mainland China and I've asked people in Taiwan and Hong Kong, and the opinion is that the listed quotation is good (altough no idea about it's official or not, I'm pretty sure the zh-cn one is official). As for your question mark about zh-hk, Hong Kong uses almost the same script as Taiwan, so zh_HK is pretty close to zh_TW on LC_MESSAGES. Ming 2005.12.19 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Frans's mail (was Re: PO format and new translations)
On Thu, Sep 21, 2006 at 01:48:35PM +0200, Jens Seidel wrote: > > Also Frans mail is still not in the archive! Please confirm that it was > send to the list. I got it from list. And I see it in archive too: http://lists.debian.org/debian-i18n/2006/09/msg00141.html Ming 2006.09.22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please DO NOT waste your time translating qmail-src debconf templates
On Mon, Sep 25, 2006 at 07:20:50AM +0200, Christian Perrier wrote: > Given the attitude of the maintainer in #388952, I'm afraid that the > only sane recommendation I can make for Debian translators is to avoid > wasting their time translating the deebconf templates of the package > named "qmail-src". Christian, After (briefly) reading the bug report, I understand your frustration. Apparently Jon, the maintainer of qmail-src, feels differently about what a debconf template should and shouldn't do. I don't know how many translators agree with me, but I would suggest removing qmail-src from DDTP/DDTSS if it's easy, to make sure qmail-src is at the lowest priority on translator's list. Ming 2006.09.25 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Showing the previous string when fuzzying
On Mon, Oct 09, 2006 at 07:18:01PM +0200, Christian Perrier wrote: > > However, don't expect that we will use it in Debian soon. Being in the > freeze process, changes to gettext are very unlikely (the 0.15 > transition did break some packages already) and I doubt we will have > 0.15.1 in etch (I regret it as well, but this is just infortunate > timing, here). For large translation projects such as debian-installer, I assume it's always possible for the maintainer or tranlation coordinator to use a local new version of gettext, generate the history-aware PO files, and after the translation is finished, revert the PO files back to a format compatible with old gettext (say, strip all the "#|" comments) so that it builds fine. Is that the case? Sure, it's more work, but for debian-installer (especially level 1, as we are using different PO files for translation and building anyway) it may be worth it. Ming 2006.10.09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Showing the previous string when fuzzying
On Tue, Oct 10, 2006 at 06:39:00AM +0200, Christian Perrier wrote: > > We'll see *after* the release but I don't make any promise Definitely. When I asked that question it was meant to be "Does this sound a sane idea? And if I play with new gettext and achieve this, is it going to get deployed?", rather than "We want this now, can Christian make this happen?". :-) Ming 2006.10.10 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: help for traditional chinese related bug report
Hi Stefano, On Sat, Oct 14, 2006 at 07:31:55PM +0200, Stefano Zacchiroli wrote: > > Request for help for a traditional Chinese typo in a vim message. Full > story available at: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347420 > > Could please someone speaking traditional Chinese verify if the bug > report is right or not? I can confirm that the reporter is correct. (Although strictly speaking I am a simplified Chinese user, I can read traditional Chinese, and as this is just a commonly seen type of typo, the difference between two variants of Chinese doesn't matter.) During the attempt of preparing a patch, I am completely bewildered by vim's i18n system -- there are two PO files for zh_TW, in different encodings, and have very slight difference (two strings). As I have no idea which one (or both?) is acutally used, I patched both files. Note as a result the attached patch is a very tricky one: it patches two files with different encodings (Big5 and UTF-8), and therefore isn't valid in either encoding. However I believe it should apply cleanly, and please let me know if there are any problems or more questions. Thanks you and the vim team for your efforts on fixing l10n bugs! Ming 2006.10.15 vim-zh-tw-po.patch.gz Description: Binary data
Re: D-I translations, freeze day 6/8 14:36: 42/39/17/28/16
On Thu, Oct 19, 2006 at 07:40:20PM +0200, Christian Perrier wrote: > > - General error checking run by Davide Viti. Errors found again. > Please, translators, use the spellchecker results from > http://d-i.alioth.debian.org/spellchecker Just to point out the URL is wrong. The correct one is: http://d-i.alioth.debian.org/spellcheck/ Ming 2006.10.19 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Different translations for a single string in debian installer
On Mon, Oct 23, 2006 at 06:55:12PM +0930, Clytie Siddall wrote: > > >For example > > > >msgid "none[ case 1, none refers to partition ]" > > > >msgid "none[ case 2, non refers to disk ]" > > If we can't use msgctxt yet, can't we put the context into the > comment fields instead? I have no idea what msgctxt is (my gettext 0.15 in Debian doesn't have it), but these comments are read by the program, so I believe you can't put it in the comments. > Putting context into the msgid field only causes confusion. Too > often, translators end up translating it or retaining it, both of > which are incorrect, as you said further down. My understanding, from reading Christian's mail, is that while translating or retaining the comments is technically incorrect, practically it won't have any effects on the program output as long as the space after '[' is kept. Ming 2006.10.23 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Different translations for a single string in debian installer
On Wed, Oct 25, 2006 at 04:44:38PM +0930, Clytie Siddall wrote: > On 23/10/2006, at 7:15 PM, Ming Hua wrote: > > >>If we can't use msgctxt yet, can't we put the context into the > >>comment fields instead? > > > >I have no idea what msgctxt is (my gettext 0.15 in Debian doesn't have > >it), but these comments are read by the program, so I believe you > >can't > >put it in the comments. > > msgctxt is a formal context field, e.g. > > msgctxt "This is a button: keep it short" > msgid "Convert" > msgstr "Đổi" Clytie, thanks for clarifying and asking on translation-i18n. Also thanks Bruno and Danilo for the more detailed explanation. I misunderstood Clytie and thought msgctxt is a command line tool like msgfmt and msgcat. Now I can confirm that gettext 0.15 in Debian indeed support msgctxt. (Well, at least the info page has the information about msgctxt and msgcat doesn't complain about a PO file with msgctxt field. :-) Ming 2006.10.26 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Work started on Release Notes for Etch (II)
A few notes from my experience, hopefully also useful for fellow translators who are not very familiar with the debian-doc working flow. On Wed, Nov 01, 2006 at 05:44:27AM +0100, Frans Pop wrote: > > See [1] for general information on how to get a checkout from the DDP CVS. > * To get an anonymous CVS checkout of the Etch Release Notes, now use: > $ cvs -d :pserver:[EMAIL PROTECTED]:/cvs/debian-doc login > $ cvs -d :pserver:[EMAIL PROTECTED]:/cvs/debian-doc -z3 \ > checkout ddp/manuals.sgml/release-notes For those who don't like deep directory structure like me, adding "-d release-notes" after the checkout command would be useful. > To build the release notes yourself, you will need to install the package > debiandoc-sgml. To build your translation, make sure you are in the > directory for your translation and use: > $ make architecture=i386 Note that debiandoc-sgml seems to only satisfy the HTML doc building requirements. To build the PS and PDF docs as well, tetex-bin and other LaTeX packages are needed. However, for only proofreading purpose, the HTML version is good enough, so you can build only the HTML doc by: $ make architecture=i386 html Ming 2006.11.05 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
