Re: Czech translation needs fixups
On Wed, 2005-10-05 at 10:30 -0400, Pavel Roskin wrote: I think your translation of %s in %d file is incorrect. There are no bytes in the message. It's file that should be plural. When tested, I got 72 byty byte v 1 souborech, which doesn't look right. Yes, the string is definitely not right. It's for the first time I see the plural construct in the po file, as I'm not a translator actually ;) I assumed that: #, fuzzy, c-format msgid %s byte msgid_plural %s bytes msgstr[0] %s byt. msgstr[1] %s byt. msgstr[2] %s byt. is trying to reflect different translations for inflected languages such as Czech. We have three suffices for describing an amount: 1 - byte 2-4- byty (the last character is yacute;) 5-infinity - bytu (the last character is uring;) so because of the number of indices of msgstr[] I assumed that it's this case. Apparently it's not. The attached patch translated another missing strings and fixes ButtonBar string to fit to 6 characters. Jindrich -- Jindrich Novy [EMAIL PROTECTED], http://people.redhat.com/jnovy/ (o_ _o) //\ The worst evil in the world is refusal to think. //\ V_/_ _\_V --- mc/po/cs.po.cstrans 2005-10-04 23:15:08.0 +0200 +++ mc/po/cs.po 2005-10-06 10:05:19.0 +0200 @@ -527,9 +527,8 @@ msgstr uèení Kláves... msgid Syntax Highlighting... msgstr zvýraznìní syntaXe -#, fuzzy msgid Save setup... -msgstr ulo¾it naStavení +msgstr ulo¾it naStavení... msgid File msgstr Soubor @@ -1963,13 +1962,13 @@ msgid Modified: %s msgstr Zmìnìn:%s #. TRANSLATORS: Status changed, like in the stat(2) man page -#, fuzzy, c-format +#, c-format msgid Status:%s -msgstr Vytvoøen: %s +msgstr Stav: %s #, c-format msgid Dev. type: major %lu, minor %lu -msgstr +msgstr Typ zaøízení: vìt¹í %lu, men¹í %lu #, c-format msgid Size: %s @@ -2604,7 +2603,7 @@ msgid Usage: msgstr Pou¾ití: msgid [dev] -msgstr +msgstr [dev] msgid UP--DIR msgstr VY©-ADR @@ -2717,6 +2716,9 @@ msgid running on this terminal.\n Subshell support will be disabled. msgstr +GNU Midnight Commander je ji¾\n +spu¹tìn na tomto terminálu.\n +Podpora subshellu bude zakázána. #, c-format msgid Cannot open named pipe %s\n @@ -2998,7 +3000,7 @@ msgid ButtonBar|Help msgstr TlaèítkováLi¹ta|Pomoc msgid ButtonBar|Quit -msgstr TlaèítkováLi¹ta|Ukonèit +msgstr TlaèítkováLi¹ta|Konec msgid ButtonBar|Ascii msgstr TlaèítkováLi¹ta|Ascii @@ -3022,10 +3024,10 @@ msgid ButtonBar|Save msgstr TlaèítkováLi¹ta|Ulo¾ msgid ButtonBar|UnWrap -msgstr TlaèítkováLi¹ta|Nezalamuj +msgstr TlaèítkováLi¹ta|Nezal. msgid ButtonBar|Wrap -msgstr TlaèítkováLi¹ta|Zalamuj +msgstr TlaèítkováLi¹ta|Zalam. msgid ButtonBar|RxSrch msgstr TlaèítkováLi¹ta|RxHled @@ -3040,13 +3042,13 @@ msgid ButtonBar|Raw msgstr TlaèítkováLi¹ta|Hrubì msgid ButtonBar|Parse -msgstr TlaèítkováLi¹ta|Analyzuj +msgstr TlaèítkováLi¹ta|Rozeb. msgid ButtonBar|Unform -msgstr TlaèítkováLi¹ta|Odformátuj +msgstr TlaèítkováLi¹ta|Odform. msgid ButtonBar|Format -msgstr TlaèítkováLi¹ta|Formátuj +msgstr TlaèítkováLi¹ta|Format msgid History msgstr Historie ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Czech translation needs fixups
On Thu, Oct 06, 2005 at 10:09:26AM +0200, Jindrich Novy wrote: msgid ButtonBar|Quit msgstr Tla??tkov?Li?ta|Konec If I understand correctly how the Q_() function of glib works, the translated strings must not contain the prefix up to the | character, since glib's Q_() (perhaps due to performance issues) does not strip this prefix, except if gettext() returns the same pointer (i.e. the string has no translation available). So I think it should be: msgid ButtonBar|Quit msgstr Konec but the best would be to test it with glib = 2.4. -- Egmont ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: print support
On Wed, 5 Oct 2005 14:48:55 +0200 Egmont Koblinger [EMAIL PROTECTED] wrote: I send for you patch for print support (it contains small fix relatively has previously). But have problem with a2ps + utf-8, details in source a2ps doesn't support UTF-8 at all. However, if lpr of cups is invoked with an UTF-8 locale, it assumes UTF-8 encoding and correctly prints the plain text files which use UTF-8. thanks, I will think as utilize lpr, earlier lpr normally works only with koi8-r (with HP printers) ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch #4492] Patch, allowing to set port to connect for FIle transfer over SHell filesystem
URL: http://savannah.gnu.org/patch/?func=detailitemitem_id=4492 Summary: Patch, allowing to set port to connect for FIle transfer over SHell filesystem Project: GNU Midnight Commander Submitted by: boda Submitted on: Чтв 06.10.2005 at 14:19 Category: None Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open ___ Details: /#sh:[EMAIL PROTECTED]:options]/[remote-dir] This patch allows to set port connect to e.g: /#sh:[EMAIL PROTECTED]:29922/home/boda should be usefull if sshd is listening on nonstandart port. ___ File Attachments: --- Date: Чтв 06.10.2005 at 14:19 Name: mc-fish_port.patch Size: 1,47KB By: boda Patch, allowing to set port to connect for quot;FIle transfer over SHell filesystemquot; http://savannah.gnu.org/patch/download.php?item_id=4492item_file_id=5286 ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=4492 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Czech translation needs fixups
On Thu, 2005-10-06 at 10:09 +0200, Jindrich Novy wrote: On Wed, 2005-10-05 at 10:30 -0400, Pavel Roskin wrote: I think your translation of %s in %d file is incorrect. There are no bytes in the message. It's file that should be plural. When tested, I got 72 byty byte v 1 souborech, which doesn't look right. Yes, the string is definitely not right. It's for the first time I see the plural construct in the po file, as I'm not a translator actually ;) I assumed that: #, fuzzy, c-format msgid %s byte msgid_plural %s bytes msgstr[0] %s byt. msgstr[1] %s byt. msgstr[2] %s byt. is trying to reflect different translations for inflected languages such as Czech. Your assumption is correct. However, be careful - the numbers in brackets are values returned by the formula in the beginning of the *.po file on the Plural-Forms: line. These are not example numbers (0 bytes, 1 byte, 2 bytes etc). It would be great to improve gettext to show the lowest number to match the rule rather than some abstract rule number. We have three suffices for describing an amount: 1 - byte 2-4- byty (the last character is yacute;) I have fixed that. It was plain y in your patch. 5-infinity - bytu (the last character is uring;) You may need to fix Plural-Forms: if that's true. There is a disagreement between what gettext 0.14.4 manual says about Czech language (which is what you say) and the rules used in cs.po included with gettext, which treat e.g. 22 like 2. I took the rules from gettext's cs.po. so because of the number of indices of msgstr[] I assumed that it's this case. Apparently it's not. I don't understand what you mean. The attached patch translated another missing strings and fixes ButtonBar string to fit to 6 characters. Applied. I actually forgot to commit the previous patch, so I had to apply your changes manually, but now they are in CVS. You didn't reply about %s in %d file. I did some research using Google and came with reasonable translations, but I'm not sure I got the v/ve thing correct. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Czech translation needs fixups
On Thu, 2005-10-06 at 11:03 +0200, Egmont Koblinger wrote: On Thu, Oct 06, 2005 at 10:09:26AM +0200, Jindrich Novy wrote: msgid ButtonBar|Quit msgstr Tla??tkov?Li?ta|Konec If I understand correctly how the Q_() function of glib works, the translated strings must not contain the prefix up to the | character, since glib's Q_() (perhaps due to performance issues) does not strip this prefix, except if gettext() returns the same pointer (i.e. the string has no translation available). You are right. I don't like the glib implementation. It totally ignores the fact that translators are not programmers, and that they will translate everything, no matter what you tell them. So I think it should be: msgid ButtonBar|Quit msgstr Konec but the best would be to test it with glib = 2.4. It's working fine with glib 2.6.6 because it doesn't include glib/gi18n.h when glib.h is included. If I include glib/gi18n.h, bad things do happen. I hope when glib/gi18n.h is included in glib.h, it will be mature enough to avoid such stupidities. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Czech translation needs fixups
On Thu, Oct 06, 2005 at 01:08:46PM -0400, Pavel Roskin wrote: You are right. I don't like the glib implementation. It totally ignores the fact that translators are not programmers, and that they will translate everything, no matter what you tell them. I perfectly agree with you. Should we file a bugreport (enhancement request?) to Gnome Bugzilla? But even if they accept our arguments and fix it, if we want to allow ButtonBar|Konec style translations in mc, we'll have to use our own implementation of Q_() if glib is older than 2.X, so then a more complicated test will be needed, the simple #ifdef Q_ won't do it. H, maybe my idea of using glib's Q_() wasn't a good idea? It seems now that it would be easier to go our own way... -- Egmont ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Czech translation needs fixups
Hello Pavel, On Thu, 2005-10-06 at 12:39 -0400, Pavel Roskin wrote: On Thu, 2005-10-06 at 10:09 +0200, Jindrich Novy wrote: On Wed, 2005-10-05 at 10:30 -0400, Pavel Roskin wrote: Your assumption is correct. However, be careful - the numbers in brackets are values returned by the formula in the beginning of the *.po file on the Plural-Forms: line. These are not example numbers (0 bytes, 1 byte, 2 bytes etc). Ok, thanks for the clarification! It would be great to improve gettext to show the lowest number to match the rule rather than some abstract rule number. We have three suffices for describing an amount: 1 - byte 2-4- byty (the last character is yacute;) I have fixed that. It was plain y in your patch. I was correct in the original patch, sorry. Only plain y without any accents is suitable here. 5-infinity - bytu (the last character is uring;) You may need to fix Plural-Forms: if that's true. There is a disagreement between what gettext 0.14.4 manual says about Czech language (which is what you say) and the rules used in cs.po included with gettext, which treat e.g. 22 like 2. I took the rules from gettext's cs.po. Yes, the Plural-Forms expression isn't correct for Czech inflection (the rule in the cs.po file looks more like a rule definition for ordinal numeral suffices) and the correct rule should be like this: Plural-Forms: nplurals=3; plural=(n==1 ? 0 : n=2 n=4 ? 1 : 2);\n what returns the correct result even for 0 (result=2). This should match perfectly messages like You have %llu bytes free on your drive. The attached patch translated another missing strings and fixes ButtonBar string to fit to 6 characters. Applied. I actually forgot to commit the previous patch, so I had to apply your changes manually, but now they are in CVS. You didn't reply about %s in %d file. I did some research using Google and came with reasonable translations, but I'm not sure I got the v/ve thing correct. Your research is correct, the ve is used only in case of 2-4 files. I know my native language is a bit brutal and not very intuitive ;) Thanks, Jindrich -- Jindrich Novy [EMAIL PROTECTED], http://people.redhat.com/jnovy/ (o_ _o) //\ The worst evil in the world is refusal to think. //\ V_/_ _\_V ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Czech translation needs fixups
Hello Pavel, Egmont, On Thu, 2005-10-06 at 13:08 -0400, Pavel Roskin wrote: On Thu, 2005-10-06 at 11:03 +0200, Egmont Koblinger wrote: On Thu, Oct 06, 2005 at 10:09:26AM +0200, Jindrich Novy wrote: msgid ButtonBar|Quit msgstr Tla??tkov?Li?ta|Konec If I understand correctly how the Q_() function of glib works, the translated strings must not contain the prefix up to the | character, since glib's Q_() (perhaps due to performance issues) does not strip this prefix, except if gettext() returns the same pointer (i.e. the string has no translation available). You are right. I don't like the glib implementation. It totally ignores the fact that translators are not programmers, and that they will translate everything, no matter what you tell them. So I think it should be: msgid ButtonBar|Quit msgstr Konec but the best would be to test it with glib = 2.4. It's working fine with glib 2.6.6 because it doesn't include glib/gi18n.h when glib.h is included. If I include glib/gi18n.h, bad things do happen. I hope when glib/gi18n.h is included in glib.h, it will be mature enough to avoid such stupidities. So the preferred way is to omit everything before the pipe sign in the translated strings to keep compatibility with older glibs ? Jindrich -- Jindrich Novy [EMAIL PROTECTED], http://people.redhat.com/jnovy/ (o_ _o) //\ The worst evil in the world is refusal to think. //\ V_/_ _\_V ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Czech translation needs fixups
On Thu, 2005-10-06 at 20:50 +0200, Jindrich Novy wrote: I hope when glib/gi18n.h is included in glib.h, it will be mature enough to avoid such stupidities. So the preferred way is to omit everything before the pipe sign in the translated strings to keep compatibility with older glibs ? Yes, except that it's for compatibility with new glib. The bug is already filed: http://bugzilla.gnome.org/show_bug.cgi?id=164373 -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Czech translation needs fixups
On Thu, 2005-10-06 at 20:46 +0200, Jindrich Novy wrote: 2-4- byty (the last character is yacute;) I have fixed that. It was plain y in your patch. I was correct in the original patch, sorry. Only plain y without any accents is suitable here. Fixed. Yes, the Plural-Forms expression isn't correct for Czech inflection (the rule in the cs.po file looks more like a rule definition for ordinal numeral suffices) and the correct rule should be like this: Plural-Forms: nplurals=3; plural=(n==1 ? 0 : n=2 n=4 ? 1 : 2);\n what returns the correct result even for 0 (result=2). This should match perfectly messages like You have %llu bytes free on your drive. Fixed. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Czech translation needs fixups
On Thu, 2005-10-06 at 19:52 +0200, Egmont Koblinger wrote: On Thu, Oct 06, 2005 at 01:08:46PM -0400, Pavel Roskin wrote: You are right. I don't like the glib implementation. It totally ignores the fact that translators are not programmers, and that they will translate everything, no matter what you tell them. I perfectly agree with you. Should we file a bugreport (enhancement request?) to Gnome Bugzilla? As I said, it's already there: http://bugzilla.gnome.org/show_bug.cgi?id=164373 But it looks like it will never be fixed. But even if they accept our arguments and fix it, if we want to allow ButtonBar|Konec style translations in mc, we'll have to use our own implementation of Q_() if glib is older than 2.X, so then a more complicated test will be needed, the simple #ifdef Q_ won't do it. There is only one glib (unlike e.g. libc), so checking for glib version would be adequate. H, maybe my idea of using glib's Q_() wasn't a good idea? It seems now that it would be easier to go our own way... Maybe. I still like the shorter name, and I don't want to change it back and forward. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[patch #4492] Patch, allowing to set port to connect for FIle transfer over SHell filesystem
Follow-up Comment #1, patch #4492 (project mc): A couple of general comments: - Please use the -p switch for diffs. This way it's obvious which function is affected. - Do not remove empty lines (at least not as integral part of a functional patch). They increase readability. - Do not use C99 style comments (//). And with regard to the code: + char port[255]; This is a rather big string to store the representation of an integer. Give it a sensible size or allocate it dynamically (and don't forget to release it). +if (flags (FISH_FLAG_RSH|FISH_FLAG_COMPRESSED)) + SUP.port = flags; +else + SUP.port = 22; SUP.flags = flags; This is an ugly hack. Firstly the flags have nothing to do with the port number, secondly it ignores the case where port 4 or more flags are defined and thirdly you assign a bogus value to SUP.flags if you do use flags to represent the port number. + if (SUP.flags (FISH_FLAG_RSH | FISH_FLAG_COMPRESSED))//port And here you make the same ugly assumption. Why don't you use SUP.ports instead? Please supply a proper patch. ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=4492 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
