[Cooker] [Bug 6199] [Installation] Bad translation and non-localized term during installation.
http://qa.mandrakesoft.com/show_bug.cgi?id=6199 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-22-10 15:53 --- Thanks, I'll fix it. (PS: the character of the second picture is also present on various other places; you may want to look at the "DrakX" module at http://www.mandrakelinux.com/l10n/zh_TW.php3 ) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: Mandrakes 9.2 RC1 | zh_TW: Bad translation are found during installation. Please refer to attach pictures.
[Cooker] [Bug 6169] [miniChinput] Cannot launch miniChinput
http://qa.mandrakesoft.com/show_bug.cgi?id=6169 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 --- Additional Comments From [EMAIL PROTECTED] 2003-20-10 12:22 --- The problem is that file (~/.qt/qtrc) is only created when localedrake is launched; if the system default is chinese and a user is added and localedrake is not launched, then that file is not created, and the default of Qt is not good for minichinput... Now, the safe value can be put in /etc/qtrc file, and then if will be the default for all users without a specific ~/.qt/qtrc It was however too late for the standard 9.2 version; but an update of qt3 will solve it; in the meantime, you can write the following in /etc/qtrc: [General] XIMInputStyle=Over The Spot -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: ASSIGNED creation_date: description: This bug exists in Mandrake Linux 9.2 download edition. Chinese input bugs. Some Chinese users find that they cannot use miniChinput which is in the 9.2 CDs to input Chinese. And an easy way to solve this bug is find: modify "~/.qt/qtrc", under the "[general]", you'll find "XIMInputStyle=On The Spot", change it to "XIMInputStyle=Over The Spot", and it will be all right. I don't know why MandrakeSoft's developer choose "XIMInputStyle=On The Spot" as default. It is easy to fix the bug, but will stop many newbie to use Mandrake. I hope you will fix the bug soon.
[Cooker] [Bug 6017] [libslang1] slang programs and UTF-8 (was: unicode_start)
http://qa.mandrakesoft.com/show_bug.cgi?id=6017 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] Status|UNCONFIRMED |NEW Component|console-tools |program Ever Confirmed||1 Product|console-tools |libslang1 Platform|PC |All Summary|unicode_start |slang programs and UTF-8 ||(was: unicode_start) Version|0.2.3-44mdk |1.4.9-3mdk --- Additional Comments From [EMAIL PROTECTED] 2003-03-10 17:24 --- mc and drakxtools (libnewt based in fact) doesn't use ncruses, but S-lang. Yes, S-lang hasn't proper utf-8 support currently -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: I just recetnly instalated MDK 9.2 RC2 I hoped this bug will fixed. It is problem with ncuses based programs like mc or drackconf under console. The problem manifest when I run unicode_start to switch the console to unicode I tryed with diffrent locales i use export LC_ALL=sr_YU.UTF-8 and I also tryed POSIX us .. but this is not a problem. bug manifest that mc dialogs are diplayed with some weird shifting and lot of black space around mc Maybe the fonts are to blame but I am not 100% surecent. Thank you very much I hope there is some solution.
[Cooker] [Bug 4454] [Installation] Mandrake uses the wrong consolefonts for pt_BR
http://qa.mandrakesoft.com/show_bug.cgi?id=4454 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-03-10 16:47 --- lat0-16.psf font does have that character; the problem was most likely not in the font, but in consolechars not properly loading it. It seems fixed now, at least I can properly display ã character -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: Mandrake uses the lat0-16 as the consolefont for pt_BR, however this charset don't have the "ã" (a-tilde). This happens in the terminal mode (no X11). Just try: consolechars -f /usr/lib/kbd/consolefonts/lat0-16.psf.gz test: ã # shouldn't work, it should print "a" consolechars -f /usr/lib/kbd/consolefonts/lat1-16.psf.gz teste: ã # should work, it should print "ã" I hope that could be fixed in MKD9.2
[Cooker] [Bug 5368] [fonts-ttf-west_european] Netscape Fonts are crap in MDK 9.2
http://qa.mandrakesoft.com/show_bug.cgi?id=5368 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-25-09 17:43 --- It is unrelated to fonts-ttf-west_european. The problem was the non installation of the XFree86-75dpi-fonts package due to a problem in the package selection before install in RC. it's fixed now (note also that it only was a concern for programs using old X11 font technology; programs and toolkits using Xft/fontconfig are able to pick any available font and display it nicely, then don't rely on some bitmap fonts with hardwired font names) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: As in summary, they ware fine in mdk9.1 and previous, a screenshot of the writing of this bug report is at http://spazioinwind.libero.it/nonsolomicrosoft/nnsf.png To have an idea of how it was before, look at netscape in windows.
[Cooker] [Bug 5009] [console-tools] Console Uzbek keymap
http://qa.mandrakesoft.com/show_bug.cgi?id=5009 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-25-09 17:16 --- it is now inb console-tools -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: Uzbek-cyrillic unicode keymap for console.
[Cooker] [Bug 5940] [Installation] Wrong default keyboard suggestion
http://qa.mandrakesoft.com/show_bug.cgi?id=5940
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEEDINFO|UNCONFIRMED
--- Additional Comments From [EMAIL PROTECTED] 2003-24-09 19:30 ---
Kaixo!
Compose works very well (it is by default on the key at the right of the
AltGr key; I don't know if that is a key with a small window or with
a small menu printed on it, I have a sticker on those keys :)
Well with that key (called Multi_key in X), you can type almost anything
in an easy to remember way. All latin accented letters, by pressing one
after the other:
, ,
being any of a,A,b,B,c,C,...z,Z
and being one of:
for the acute accent
("backquote") for the grave accent
(:) for diaeresis
(") for the double acute accent
(>) for the circumflex accent
(<) for the caron
for the cedilla
for the ogonek
<0> for the ring above
for the dot above
for the dot below or the comma below (under 't' and 's' for the
romanian letters)
for the diagonal-barred letters (o and l)
for the macron (over wowels) or an horizontal slash (for h, t)
(~) for the tilde
for the breve
"ae" and "oe" can be typed withand
for uppercase ones "AE", "OE" the same but with uppercase.
aring (å) and schwa (a sort of refversed e) can be typed with
andrespectively
quotes can be typed the same way,
Multi_key + < + < --> «
Multi_key + > + > --> »
try also (you need to be under an utf-8 locale to see them):
Multi_key + " + >
Multi_key + > + "
Multi_key + < + "
Multi_key + " + <
Multi_key + ' + >
Multi_key + > + '
Multi_key + < + '
Multi_key + ' + <
Multi_key + ( + c --> ©
Multi_key + ( + r --> ®
Multi_key + T + M --> TM sign
etc.
The combinations available depend on the locale; on an UTF-8 locale
you can type them all.
do a "grep '^' /usr/X11R6/lib/X11/locale//Compose" for the full
list; with x being "iso8859-15" is you are in an iso-8859-15
locale, "iso8859-2" for an iso-8859-2 locale, etc; and "en_US.UTF-8"
for an UTF-8 locale.
To know the encoding of your locale, type "locale charmap" on the
command line.
Note that it is also those Compose files that define what dead keys can
do (eg lines like: : "á" aacute)
--
Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Reminder: ---
assigned_to: [EMAIL PROTECTED]
status: UNCONFIRMED
creation_date:
description:
I installed Mandrake with "Nederlands" (Dutch) as the default language. It then
suggests
a few keyboards, and the default choice annex suggestion is "US International"; this
is
incorrect, our default keyboard is "US".
[Cooker] [Bug 5940] [Installation] Wrong default keyboard suggestion
http://qa.mandrakesoft.com/show_bug.cgi?id=5940 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |NEEDINFO Ever Confirmed||1 --- Additional Comments From [EMAIL PROTECTED] 2003-24-09 17:47 --- Well, as what is proposed is a *choice* list, there isn't any real "default"; I mean, there is not a value pre-set that you have to unset if you don't want it; The order of preference could be changed; what should it be ? (I'm also a bit surprised to read Dutch keyboards are not sold on NL; where does the Dutch keyboard layout come from then? or was it sold some time ago and fall in disuse?) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEEDINFO creation_date: description: I installed Mandrake with "Nederlands" (Dutch) as the default language. It then suggests a few keyboards, and the default choice annex suggestion is "US International"; this is incorrect, our default keyboard is "US".
[Cooker] Re: Chinese and other i18n problems with Sept 19 cooker.
No, it does nothing (it is only used by CJK version of rxvt). the important thing is that localedrak wrote that XIM should be Over the Spot in the ~/.qt/qtrc file (maybe libqt should be patched to make that value the default) > zh_TW: > Using localedrake to change the locale to traditional chinese/taiwan gives > ~/.i18n locale to be zh_TW. I deleted ~/.openoffice to be safe. Upon KDE > restart kwrite still would not display traditional characters. kedit, gedit, > openoffice all worked fine. xcin was the IME. Kwrite seems to use its own display code, different of the rest of KDE, and buged :( > So I deleted ~/.kde, ~/.qt, and ~/.openoffice and restarted KDE. This time > all the KDE menus were missing characters (must be using a simplified font). If you delete ~/.kde/share/config/kdeglobals, you also delete the info on the default font. Apparently Qt/KDE takes the first font with chinese charaters, without doing any distinction between traditional and simpliifed. 50% of chances of being wrong... fontconfig gives information on charset coverage and language coverage for each font; so maybe a future version of Qt could use that info to better choose the fonts (or even better: try to find missing glyphs from other fonts, as gtk does; which would take away the need to provide a default font) > Incidentally, using gbrxvt with zh_CN.UTF-8 does not work well. Indeed, rxvt doesn't support UTF-8 at all. > Chinese (and other language) support has come a long ways, and it is beginning > to look really good. Indeed, the only real CJK-specific problem in all you reported is the bug of kwrite with ami; and the fact that Qt should better default to Over the Spot, to be safer when conection to an XIM without good On the Spot support is done. All the rest is not CJK specific (they are font problems in Qt and kwrite, and lack of proper UTF-8 support on some few old programs) Another, not reported, CJK problem is the fact you cannot switch of input method (other than calling localedrake, login out, and relogging; which is not very user friendly), this is due to an XFree86 limitation. Only "yudit" (a unicode text editor) is able to do it (it allows to connect to various different XIM, and you can switch between them with a menu) > It's very nice to be able to switch between languages > on the same machine. (Perhaps in six months or a year Mandrake can move > completely to Unicode and change IME's on the fly.) The IME switching problem will take more time I'm affraid... (with gtk it would maybe be possible to implement the same behaviour as yudit, as gtk provides a way to develop gtk-specific input methods; for Qt I don't know). > vic -- Ki ça vos våye bén, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portuguese] pgp0.pgp Description: PGP signature
[Cooker] [Bug 5645] [xterm] Deleting Arabic text in terminals in response to an interactive command using BACKSPACE will delete the question itself!
http://qa.mandrakesoft.com/show_bug.cgi?id=5645 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2003-19-09 16:40 --- Kaixo! On Fri, Sep 19, 2003 at 03:57:28PM +0200, [munzirtaha] wrote: It is probably tied to libreadline (it isn't related to terminals) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEEDINFO creation_date: description: When you type any interactive command in the console (e.g. rm), you will be faced with a question such as: rm: remove regular file `filename'? Now, if you switch to Arabic and type some Arabic letters then BACKSPACE to delete them, you will delete letters from the question itself which is equal to the number of the typed Arabic letters. Looks as if something concerned with Arabic being double byte and the UTF-8 encoding. This problem is in konsole, xterm, mlterm.
[Cooker] [Bug 4316] [console-tools] /sbin/setsysfont segfaults on boot
http://qa.mandrakesoft.com/show_bug.cgi?id=4316 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-18-09 15:27 --- *** Bug 3438 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: /sbin/setsysfont segfaults on boot and the console font never gets set.
[Cooker] [Bug 3438] [locales-el] greek fonts do not appear in text mode
http://qa.mandrakesoft.com/show_bug.cgi?id=3438 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-18-09 15:27 --- The reason was proably the greek font not being loaded; fixed in today's console-tools *** This bug has been marked as a duplicate of 4316 *** -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: In Greek language Installation, greek fonts are not displayed in text mode This can be seen by killing the X session or during system shutdown. When the system starts, text mode greek fonts are displayed OK. this problem apears in 9.0 and 9.1rc1 &2
[Cooker] [Bug 3665] [Installation] Warning isn't translated in RU in License Agreement
http://qa.mandrakesoft.com/show_bug.cgi?id=3665 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-18-09 15:23 --- *** Bug 4730 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: The very last paragraph in the License Agreement is not translated. 1. Begin installation of Linux Mandrake 9.1 in russian 2. Read the License Agreement and see that the last paragraph is not translated.
[Cooker] [Bug 4730] [Installation] Part of license isn't translated
http://qa.mandrakesoft.com/show_bug.cgi?id=4730 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-18-09 15:23 --- the string is translatable now; thanks *** This bug has been marked as a duplicate of 3665 *** -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: During Mandrake installation the license is displayed. But not whole in choosen language - the last paragraph isn't translated on any languages: Warning: Free Software may not necessarily be patent free, and some Free Software included may be covered by patents in your country. For example, the MP3 decoders included may require a licence for further usage (see http://www.mp3licensing.com for more details). If you are unsure if a patent may be applicable to you, check your local laws. It needs to be put to gi/perl-share/install/po/Drakx.pot
[Cooker] [Bug 3665] [Installation] Warning isn't translated in RU in License Agreement
http://qa.mandrakesoft.com/show_bug.cgi?id=3665 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-18-09 15:20 --- N( ) was missing aroung it; it is fixed on CVS source, it now just needs translations -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: The very last paragraph in the License Agreement is not translated. 1. Begin installation of Linux Mandrake 9.1 in russian 2. Read the License Agreement and see that the last paragraph is not translated.
[Cooker] [Bug 4316] [console-tools] /sbin/setsysfont segfaults on boot
http://qa.mandrakesoft.com/show_bug.cgi?id=4316 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] ||bremen.de --- Additional Comments From [EMAIL PROTECTED] 2003-18-09 14:53 --- *** Bug 5230 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: /sbin/setsysfont segfaults on boot and the console font never gets set.
[Cooker] [Bug 5230] [initscripts] Cyrillic Uzbek translation does not work
http://qa.mandrakesoft.com/show_bug.cgi?id=5230 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-18-09 14:53 --- Indeed the problem was in console-tools (it no longer read gziped fonts) It's fixed now *** This bug has been marked as a duplicate of 4316 *** -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: During boot and shutdown/reboot the Cyrillic Uzbek characters are not displayed properly. The same when (re)starting/stopping services in text mode console. On graphic console it works fine. Thanks.
[Cooker] [Bug 4316] [console-tools] /sbin/setsysfont segfaults on boot
http://qa.mandrakesoft.com/show_bug.cgi?id=4316 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-18-09 14:04 --- the problem was with compressed console fonts; as a workaround the fonts have been decompressed in console-tools-0.2.3-45mdk -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: /sbin/setsysfont segfaults on boot and the console font never gets set.
[Cooker] [Bug 5008] [console-tools] Extended cyrillic console font
http://qa.mandrakesoft.com/show_bug.cgi?id=5008 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-18-09 12:14 --- done -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: It includes all glyphs from UniCyr_8x16 and in addition most glyphs of the Unicode "Extended Cyrillic" table (0x480-0x4ff). Uzbek, Tajik, Mongolian, and Azerbaijani i18n teams will benefit from it.
[Cooker] [Bug 5542] [mdk-menu-messages] Missing strings from mandrake-simplified menu in i18n packages
http://qa.mandrakesoft.com/show_bug.cgi?id=5542 --- Additional Comments From [EMAIL PROTECTED] 2003-17-09 09:31 --- Fixed in mdk-menu-messages-9.2-6mdk Thanks for reporting the problem -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: Some strings are missing in menu-messages-cs.po file and therefore is not possible to localize them. For example: Chat using AIM, ICQ, MSN, Yahoo, Winpopup Chat using IRC Write and stick notes
[Cooker] [Bug 5542] [mdk-menu-messages] Missing strings from mandrake-simplified menu in i18n packages
http://qa.mandrakesoft.com/show_bug.cgi?id=5542 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-17-09 09:26 --- Fixed in mdk-menu-messages-9.2-6mdk Thanks for reporting the problem -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: Some strings are missing in menu-messages-cs.po file and therefore is not possible to localize them. For example: Chat using AIM, ICQ, MSN, Yahoo, Winpopup Chat using IRC Write and stick notes
[Cooker] [Bug 5450] [ispell-pl] Package is not usable (obsolete)
http://qa.mandrakesoft.com/show_bug.cgi?id=5450 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-09-09 21:39 --- ispell is no longer used aspell is used instead (only ispell packages remaining are those for which there isn't yet an aspell version; which is not the case of Polish that has aspell-pl-0.50.2-2mdk). ispell-pl (and other ispell-* obsoleted by aspell-* equivalents) has been removed and won't be in 9.2 Thanks -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: I prepared ispell-pl package highly recommended to update. Why? The official package is very obsolete and broken. Marek Futerga - polish programmer prepared engine for creating ispell and aspell.pl (it's available at http://www.kurnik.pl/slownik/ort/) and many people are working on these packages. Most of people using Mandrake uses these packages because they cannot normally use official version of ispell (maitained at ispell-pl.sf.net). Is it possible to alter the package ispell-pl-0.8 onto package prepared by me? I put this onto ftp.linux-mandrake.com/incoming as ispell-pl-0.8alt.7mdk.noarch.rpm I can prepare new rpms for this package based on daily snapshot from kurnik.pl page. I really would like to see this package in MDK before 9.2 releasing. People need this :) This package is also available at: http://www.bilgoraj.lbl.pl/ispell-pl-0.8alt-7mdk.noarch.rpm
[Cooker] [Bug 5363] [Installation] Britain incorrectly located in America section
http://qa.mandrakesoft.com/show_bug.cgi?id=5363 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-09-09 18:54 --- Standard british English is also spoken on american continent (Canada and Caraibs for example). So it is correct that it also appears there (in fact it appears in all 5 continent branchs) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: When you choose the language for the install, the UK (Britain) is included in the America (should be spelt Americas) section and not in Europe where it rightly belongs
[Cooker] [Bug 5162] [lyx] Missing Fonts in Lyx
http://qa.mandrakesoft.com/show_bug.cgi?id=5162 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-09-09 16:58 --- The package has been made, and lyx made to depend on it. (there is no problem at all with Russian locale; at least I didn't saw anything strange) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: Hey everyone, Lyx is missing the font package that allows it to display LaTex characters on screen. The appropriate package can be found at http://ev-en.org/wiki/moin.cgi/LyxQtFAQ Also, would it be possible to have the QT version of Lyx installed by default? Thanks a lot! Take care, Onsi
Re: [Cooker] ls and utf8 names
Kaixo! On Sun, Sep 07, 2003 at 12:59:53AM +0200, J.A. Magallon wrote: > > MacOS X uses UTF-8. > > Change LC_CTYPE=en_ES.UTF-8 and you will see them. > > Tests... > > werewolf:~/t> LC_CTYPE=es_ES.UTF-8 ls > queÌ/ you need obviously to set your terminal to be able to display UTF-8. Note also that it uses combinaed accent 'e + acute accent' instead of a single 'é' char... >> Your best solution to exchange disk space between both systems >> would be, imho, to use UTF-8 in linux. > > No shared storage. I copy the files via scp. So what I really like > woudl be an option for ext3...that looks missing. No, if you copy by scp, then the only way to handle it is trough scp protocol. You may suggest to ssh author to add an extra comand line option to tell the charset encoding at the other end, and to perform charset conversion of filename when copying. eg: scp --remote-encoding=utf-8 [EMAIL PROTECTED]:~bla/ble/bli.txt . would convert "bli.txt" from utf-8 to local encoding if needed. such a parameter could also be used by slogin to convert I/O; it would be quite useful indeed, and the mantainer may agree on adding it. His email: Damien Miller <[EMAIL PROTECTED]> > > Or manually rename them (or you can do a small script to do it, > > with iconv) > > Will look at how it works. But there is an extra difficulty, due to combining accents... it doesn't seem iconv is able to handle it; you should then first change to precomposed utf-8 strings; then convert. -- Ki ça vos våye bén, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portuguese] pgp0.pgp Description: PGP signature
[Cooker] [Bug 5289] [locales-he] CONSOLE_NOT_LOCALIZED=yes has not effect
http://qa.mandrakesoft.com/show_bug.cgi?id=5289 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-07-09 13:28 --- CONSOLE_NOT_LOCALIZED=yes is now fixed on CVS. reversing translation strings may not a good idea, as for mdk tools a lot of strings are common for both gtk and ncurses interfaces. I understand it was a good workaround when no real bidi support existed; but currently it may be better. If you would like I add another variable to also disable translations on xterms, just tell me. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: (i hope this is the correct package to report...) anywany, rc1, out of the box, the string is in /etc/sysconfig/i18n and I still get a "hebrew" console. The problem is that I get squares and stuff instead of "reversed herew", on the other hand I can always blame acon on this, since it should not be installed in whith hebrew. We like our hebrew reversed by hand. aka visual, this is the translation used by make for example (hopefully i will have time to reverse also urpmi before rc2 or final).
[Cooker] [Bug 4409] [miniChinput] Cannot launch miniChinput
http://qa.mandrakesoft.com/show_bug.cgi?id=4409
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||FIXED
--- Additional Comments From [EMAIL PROTECTED] 2003-07-09 13:19 ---
miniChinput has been updated.
Qt is already configured for "Over The Spot" when choosing Chinese at install
time or trough localedrake; or it should do.
Can you look at your $ENV{HOME}/.qt/qtrc file, XIMInputStyle option;
Thanks
--
Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Reminder: ---
assigned_to: [EMAIL PROTECTED]
status: RESOLVED
creation_date:
description:
I've installed 9.2beta1 with zh_CN locale. As described in 4408, miniChinput was
not installed by default.
So, I installed it by hand from RPMDrake. After restarting X, I couldn't input
Chinese, either. The doc says I should press Ctrl+Space to invoke the IME, but
nothing happened when I pressed it. The alphabet keys I pressed are still
English letters which will appear on the screen as it is.
[Cooker] [Bug 5230] [initscripts] Cyrillic Uzbek translation does not work
http://qa.mandrakesoft.com/show_bug.cgi?id=5230 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |NEEDINFO Ever Confirmed||1 --- Additional Comments From [EMAIL PROTECTED] 2003-07-09 13:10 --- what is the content of your /etc/sysconfig/i18n file ? (always include it when reporting i18n problems). if you set SYSFONT=koi8-k and no SYSFONTACM line, and no UNIMAP line; does it works correctly ? -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEEDINFO creation_date: description: During boot and shutdown/reboot the Cyrillic Uzbek characters are not displayed properly. The same when (re)starting/stopping services in text mode console. On graphic console it works fine. Thanks.
[Cooker] [Bug 4596] [initscripts] Unreadble characters in zh/jp locale
http://qa.mandrakesoft.com/show_bug.cgi?id=4596 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-07-09 13:06 --- fixed on CVS -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: I've installed 9.2beta2 in zh_CN locale. Thanks for the new bootsplash. But, when I press F2 to see the detail log, the letters became unreadable. I think the new bootsplash are fully drawn in graphic mode, so there is no problem displaying Chinese correctly using correspoding pixel font. Otherwise, disable languages other than western for now.
Re: [Cooker] ls and utf8 names
Kaixo > A little question: I copy files from OSX to my cooker box. They are > UTF-8 encoded. I can't manage to see accents in ls (original name is 'qué'): > > werewolf:~/t> ls > queÌ?/ > > werewolf:~/t> env | grep LC > LC_CTYPE=es_ES.ISO-8859-15 MacOS X uses UTF-8. Change LC_CTYPE=en_ES.UTF-8 and you will see them. (if the kernel has support for charset conversion for the filesystem used by MacOS X you could put the right options on /etc/fstab so the conversion is done when copying files. mount man page seems to tell the fs type is "openstep", and it tells nothing about possible iocharset option). Your best solution to exchange disk space between both systems would be, imho, to use UTF-8 in linux. Or manually rename them (or you can do a small script to do it, with iconv) -- Ki ça vos våye bén, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portuguese] pgp0.pgp Description: PGP signature
Re: [Cooker] rc1 install test
Kaixo! On Fri, Sep 05, 2003 at 06:37:38PM +0200, Thierry Vignaud wrote: > > 3. The fonts in all the GTK2 stuff look terrible. Very choppy on > > my 1024x768 LCD, which is a very common thing on laptops. The the gnome font configurator (gnome-font-properties) has fine-tuning options, some of them for LCD displays. Does it makes it better? -- Ki ça vos våye bén, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portuguese] pgp0.pgp Description: PGP signature
Re: [Victor Roetman] [Cooker] Simplified Chinese and 9.2-RC1 problems
ile you wanted to write in Chinese. Maybe 9.2 will have a special case when country is one of those where Chinese is used, and in such case enable Chinese langugage support and input; it is being discussed. > drakconf works fine with simplified chinese. gtk2 programs are able of finding missing glyphs from other fonts if needed; so you never have the "square box" problem (unless you don't have any single font at all with those characters of course), so we don't need to care about defining default fonts for those > I will also add that when I did "export LC_ALL=en" and "export LANG=en" and > then did startx as root, Gnome started in Chinese, LANGUAGE variable has priority over all others for the translations (that is true for all programs but KDE ones, which utilise KDE_LANG instead, and the kde config files; but in any case defining LC_ALL or LANG doesn't change the language used for interface in most modern programs; it changes however things as charset encoding, default font used, sorting order, date, number representation, monetary unit, etc.) > but the gnome panel > consistently had a segmentation fault, died, restarted, and segfaulted again. > Go figure. When they were all back at zh_CN again, there were no problems. That shouldn't happen... do you have "en" locale installed? what returns "LC_ALL=en locale charmap" ? > I ran out of time to do further testing, but I wanted to get this out so > others can look at it and think about how to solve some of these issues, and > maybe help me understand this better. Thanks. > Finally, I STRONGLY suggest making the login screen (xdm, gdm, etc) able to > change the language. That feature is dependent of the *dm; some provide it, some do not. Note however that changing the language is not enough for languages that need specific input methods. > Redhad does this by default. gdm seems to be able to > do it. People need to be able to choose their language before logging in, > and not have to negotiate menus in English. Chinese speakers (who have > little or no English) have no problems using Redhat - it all works out of the > box. It should be the same for 9.2, once the bugs get solved. Thanks -- Ki ça vos våye bén, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portuguese] pgp0.pgp Description: PGP signature
Re: [Cooker] localisation files for webapps
Kaixo! On Thu, Sep 04, 2003 at 08:28:48PM +0800, Abel Cheung wrote: > On 2003-09-04(Thu) 14:10:46 +0200, Guillaume Rousse wrote: > > Several web applications, including all horde suite and mailman, include > > localisation files under their own directory in /var/www/html. Is there a way > > to use %find_lang macro so as to look for files elsewhere as under > > /usr/share/locale ? In fact (I just looked at /usr/lib/rpm/find-lang.sh script ) it doesn't search in /usr/share/locale but in anything with "/share/locale/" in the path. Maybe it could be changed to "/locale/" ? (are there some programs using *.mo files in places wich don't have "locale" as a directory name ?) Or maybe, look for "LC_MESSAGES" directory instead ? -- Ki ça vos våye bén, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portuguese] pgp0.pgp Description: PGP signature
[Cooker] [Bug 4023] [stardict] stardict does not start
http://qa.mandrakesoft.com/show_bug.cgi?id=4023 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-04-09 18:37 --- stardict 2 is now packaged -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: when I try to start stardict-1.31-4mdk.i586.rpm I get: X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 51 (X_SetFontPath) Value in failed request: 0x287 Serial number of failed request: 112 Current serial number in output stream: 113 It might be easier to package the latest version 2.2 than fixing an old version. Please do not forget to update the description b/c v2.2 is not only an english/chinese dictionary.
[Cooker] [Bug 5184] [drakfirsttime] Arabic alignment in all of the dialog boxes in Mandrake Control center dialog boxes should be right justified.
http://qa.mandrakesoft.com/show_bug.cgi?id=5184 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] Severity|normal |minor Status|ASSIGNED|UNCONFIRMED Component|i18n|i18n Product|drakconf|drakfirsttime Version|9.2-1mdk|0.92-0.2mdk --- Additional Comments From [EMAIL PROTECTED] 2003-04-09 18:34 --- The problem is in the justification of text in first time wizard, lines are left justified, they should be right justified for RTL languages. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: Arabic alignment in all of the dialog boxes (in Mandrake 9.2 dialog boxes) is left justified. This should be right justified.
[Cooker] [Bug 5154] [console-tools] insert-button (keycode 110) equals thilde (keycode 27) in console (norwegian, no-latin1)
http://qa.mandrakesoft.com/show_bug.cgi?id=5154 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO Ever Confirmed||1 --- Additional Comments From [EMAIL PROTECTED] 2003-04-09 12:44 --- Is your keyboard a standard one, or a laptop one ? Is the insert a single key, or is that key holding various symbols, depending on a modifier. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEEDINFO creation_date: description: Turn on Compaq evo n800c, press insert, see thilde (~) sign emerge. This is when I have chosen norwegian (norsk) keyboard. In X it all works ok, no problems. this is with 9.2 rc1
[Cooker] [Bug 4664] [libgtk+1.2] Gnucash does not start : Missing character set "ISO8859-15"
http://qa.mandrakesoft.com/show_bug.cgi?id=4664 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2003-04-09 12:27 --- THe problem is not "gtk applications" but *OLD gtk1* applications. New gtk2 ones can access the ttf files directly with the same level of quality as KDE; and the Vera fonts are indeed used prioritarly for the "Sans", "Serif" and "Monospace" default fonts. The problem is gnucash and a small handfull of other programs still use old gtk1 toolkit, which uses the X11 server fonts, which has lots of drawbacks and doesn't behave very well in case of missing fonts (while new Xft technology simply searches another font if the requested one is missing) The 75 dpi bitmap font package should be installed by default, it is the better solution. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: ASSIGNED creation_date: description: Gnucash does not start on a French cooker system : The font "-adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-*" does not support all the required character sets for the current locale "fr_FR" (Missing character set "ISO8859-15") (Missing character set "ISO8859-15") Warning: gnucash_style_set_register...(): Cannot load font: -adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-* The font "-adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-*" does not support all the required character sets for the current locale "fr_FR" (Missing character set "ISO8859-15") (Missing character set "ISO8859-15") Fatal Error: gnucash_style_set_register...(): Cannot load fallback font: -adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-* The font "-adobe-helvetica-medium-o-normal--*-120-*-*-*-*-*-*" does not support all the required character sets for the current locale "fr_FR" (Missing character set "ISO8859-15") (Missing character set "ISO8859-15") Warning: gnucash_style_set_register...(): Cannot load font: -adobe-helvetica-medium-o-normal--*-120-*-*-*-*-*-* The font "-adobe-helvetica-medium-o-normal--*-120-*-*-*-*-*-*" does not support all the required character sets for the current locale "fr_FR" (Missing character set "ISO8859-15") (Missing character set "ISO8859-15") Fatal Error: gnucash_style_set_register...(): Cannot load fallback font: -adobe-helvetica-medium-o-normal--*-120-*-*-*-*-*-* The font "-adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-*" does not support all the required character sets for the current locale "fr_FR" (Missing character set "ISO8859-15") (Missing character set "ISO8859-15") Fatal Error: gnucash_style_set_register...(): Cannot load fallback font: -adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-* The font "-adobe-helvetica-medium-o-normal--*-120-*-*-*-*-*-*" does not support all the required character sets for the current locale "fr_FR" (Missing character set "ISO8859-15") (Missing character set "ISO8859-15") Fatal Error: gnucash_style_set_register...(): Cannot load fallback font: -adobe-helvetica-medium-o-normal--*-120-*-*-*-*-*-*
[Cooker] [Bug 5053] [mdk-menu-messages] French transaltion of the Configuration menu
http://qa.mandrakesoft.com/show_bug.cgi?id=5053 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-04-09 12:20 --- No, all recuperable Gnome strings have been recuperated. Still untranslated strings are not translated in Gnome or KDE desktop files either. They need to be translated in the "menu-messages" module, here: http://www.mandrakelinux.com/l10n/fr.php All the reported untranslated strings have been translated. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: Some items in the menu are not translated in french. I am using a Mandrake 9.1 upgraded to 9.2 (menu listed in french) -configuration\Autre\User Administration -configuration\Gnome\Accessibilité\Assistive technology Support -configuration\Paquetage\Browse available software -configuration\Paquetage\Software media manager -configuration\Configure your computer
[Cooker] [Bug 1209] [fonts-ttf-big5] traditional Chinese character cannot show properly on 9.1 beta 3
http://qa.mandrakesoft.com/show_bug.cgi?id=1209 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-04-09 12:00 --- The problems have been solved -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: I could not choose Traditional Chinese as default language because of no Chinese character shown. Instead, I chose Chinese as an additional language. After installation, Chinese fonts were not shown in Mandrake font tools and Mozilla. I thought the path of big5 fonts (/usr/share/font/ttf/big5/) were not added properly. Besides, xcin (the Chinese character input tools) could not launched.
[Cooker] [Bug 5245] [Mesa] 3D accel (Mesa, OpenGL) crashes with Mach 64 card
http://qa.mandrakesoft.com/show_bug.cgi?id=5245 --- Additional Comments From [EMAIL PROTECTED] 2003-04-09 11:50 --- Kaixo! On Thu, Sep 04, 2003 at 11:10:35AM +0200, [fpons] wrote: Which package should I install/update, and which steps to do to test it ? Thanks -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: I installed 9.2 RC1, and wanted to choose the 3D acceleration support (trough old XFree86 3). It installed all the needed packages, and I could boot nicely on Gnome. However, when trying KDE it crashed; in fact, all programs using opengl crashed (that include all KDE programs). I can run any needed test if I'm told what to do. my card: ATI Mach64 Utah
[Cooker] [Bug 5245] [Mesa] New: 3D accel (Mesa, OpenGL) crashes with Mach 64 card
http://qa.mandrakesoft.com/show_bug.cgi?id=5245 Product: Mesa Component: Mesa Summary: 3D accel (Mesa, OpenGL) crashes with Mach 64 card Product: Mesa Version: 5.0.1-5mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: blocker Priority: P2 Component: Mesa AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I installed 9.2 RC1, and wanted to choose the 3D acceleration support (trough old XFree86 3). It installed all the needed packages, and I could boot nicely on Gnome. However, when trying KDE it crashed; in fact, all programs using opengl crashed (that include all KDE programs). I can run any needed test if I'm told what to do. my card: ATI Mach64 Utah -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 5002] [rpmdrake] rpmdrake does not show proper strings
http://qa.mandrakesoft.com/show_bug.cgi?id=5002 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2003-02-09 20:40 --- It works correctly with rpmdrake 2.1-31mdk when called with [EMAIL PROTECTED]:uz Could you provide the version number of rpmdrake you are using (rpm -q rpmdrake), or better, test with a newer version. And also, for i18n related problems, always attach your $HOME/.i18n or /etc/sysconfig/i18n file. However, as the cyrillic translations are indeed found; I'm likely to think that the problem was with the mo file. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEEDINFO creation_date: description: I have mdk-92-rc1 in Uzbek-cyrillic ([EMAIL PROTECTED]). When "Mandrake choice" is selected rpmdrake shows strings in package-list frame in Uzbek-latin (uz_UZ). The other strings are correct. Apparently, it takes them from /usr/share/locale/uz/LC_MESSAGES/rpmdrake.mo instead of ../[EMAIL PROTECTED]/../rpmdrake.mo. When I delete this file, the strings in package-list frame are in English. Thanks.
[Cooker] [Bug 5185] [coreutils] rm -i won't work if certain environmental variables related to Arabic are set.
http://qa.mandrakesoft.com/show_bug.cgi?id=5185 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-02-09 15:46 --- try hitting the arabic letter for "yes" (it is U0646). I will redo all the arabic locales in order to also add "yY" for the yesexpr; and "Nn" for the noexpr. To see what the problem is, you can issue the command: locale -c yesexpr noexpr it shows what are the letters recognizable as a postive (respectively negative) answer to a yes/no question. $ LC_ALL=ar locale -c yesexpr noexpr LC_MESSAGES ^[ن].* LC_MESSAGES ^[ل].* As you can see, the arabic locales only define arabic letters for those. Imho the yY and nN should always be used, unless impossible. I'll report the bug to the glibc mantainers. (it is fixed in the upcoming locales locales-2.3.2-5mdk) Thanks -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: rm -i (or just rm since rm -i is an alias for rm by default in Mandrake) will not work due to certain environmental variables related to Arabic. If /etc/sysconfig/i18n contains LC_ALL=ar_SA.UTF-8, LC_ALL=ar, LC_MESSAGES=ar, ... or we export these variables manually, the rm -i command and other commands will be disabled!! [EMAIL PROTECTED] munzir]$ export LC_ALL=ar_SA.UTF-8 [EMAIL PROTECTED] munzir]$ touch arabeyes [EMAIL PROTECTED] munzir]$ ls -l arabeyes -rw-r--r-- 1 munzir munzir 0 May 6 13:48 arabeyes [EMAIL PROTECTED] munzir]$ \rm -i arabeyes rm: remove regular empty file `arabeyes'? y [EMAIL PROTECTED] munzir]$ ls -l arabeyes -rw-r--r-- 1 munzir munzir 0 May 6 13:48 arabeyes [EMAIL PROTECTED] munzir]$ \rm arabeyes [EMAIL PROTECTED] munzir]$ ls -l arabeyes ls: arabeyes: No such file or directory
[Cooker] [Bug 4300] [Installation] Selecting a language
http://qa.mandrakesoft.com/show_bug.cgi?id=4300 --- Additional Comments From [EMAIL PROTECTED] 2003-02-09 13:30 --- Kaixo! On Tue, Sep 02, 2003 at 08:49:44AM +0200, [avblokland] wrote: I don't see what you find surprising... French, English, and Spanish are official languages in various countries of the American continent. In case of dialectal variants, and if appropriate translations exist, the ones better matching your language+country combination will be chosen in priority. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: Something must be done when choosing the language. the submenu "America" is open, and we can choose: English(..), English(..), Espagnol,..., Francais, ... But 3 of these countries aren't in America! Prefer to name the first submenu "Common" and move these 6 languages into this entrie. Otherwise, confusion starts: "French, but French from Europa, of French from Canadia?"
[Cooker] [Bug 5053] [mdk-menu-messages] French transaltion of the Configuration menu
http://qa.mandrakesoft.com/show_bug.cgi?id=5053 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2003-01-09 15:40 --- Kaixo! On Sat, Aug 30, 2003 at 04:20:23PM +0200, [fcrozat] wrote: I don't know how to translate "Assistive technology Support"... I fid other; but still a lot of French strings to translate in menu-messages po file. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEEDINFO creation_date: description: Some items in the menu are not translated in french. I am using a Mandrake 9.1 upgraded to 9.2 (menu listed in french) -configuration\Autre\User Administration -configuration\Gnome\Accessibilité\Assistive technology Support -configuration\Paquetage\Browse available software -configuration\Paquetage\Software media manager -configuration\Configure your computer
[Cooker] [Bug 4744] [xmms] Not fully i18ned
http://qa.mandrakesoft.com/show_bug.cgi?id=4744 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-30-08 10:41 --- It's fixed in xmms-1.2.7-25mdk thanks -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: >From 9.1 to 9.2b2, xmms is not fully i18ned even tha latest po haved applied, see screenshot.
[Cooker] [Bug 5043] [mdk-menu-messages] Mdk9.2rc1 - Menu partialy not translated
http://qa.mandrakesoft.com/show_bug.cgi?id=5043 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-30-08 10:40 --- corrigé dans mdk-menu-messages-9.2-4mdk, merci fixed in mdk-menu-messages-9.2-4mdk, thanks -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: French version : K => Configuration => Configure your computer K => Configuration => Configure your Desktop These two lines are not translated in French.
[Cooker] [Bug 4212] [groff-for-man] A fix for bad man pages display on UTF-8 locales
http://qa.mandrakesoft.com/show_bug.cgi?id=4212
--- Additional Comments From [EMAIL PROTECTED] 2003-22-08 02:40 ---
ok, the patch is applied on
I applied it on mandoc.tmac instead of troffrc; so it only applies to man pages
and not to other uses of groff-for-man-1.19-3mdk
--
Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Reminder: ---
assigned_to: [EMAIL PROTECTED]
status: NEW
creation_date:
description:
In Mandrake 9.1, there's an installer option "Use Unicode by default".
This option causes UTF-8 versions of locales to be used, which finally moves the
distribution in the direction of unifying diverse character set encoding
standards into a single, well-known and well understood encoding: UTF-8.
However, there is a problem with some UTF-8 locales with regards to man pages.
The problem exhibits itself in hyphens (e.g. in the option names) being
displayed incorrectly and being unsearchable (the "minus" character from the
keyboard doesn't match them).
This is due to the fact that the groff utility that's used for formatting pages
(when called from the nroff shell script) formats "\-" sequence in the source
input as Unicode character "0x2212", and "-" character as Unicode character
"0x2010" instead of the backward-compatible minus sign (which has code "0x002D"
for compatibility with ASCII).
The hyphen sign "0x2212" isn't handled properly by either the less viewer, or
the output terminal and as a result it's displayed with a leading garbage
character and can't be input from the keyboard when searching in the manual page
(so that e.g. it isn't possible to search for "-h" option when reading the
manual for ls).
Among others, the "en_US.UTF-8" locale is influenced by this bug. OTOH, some
other locales (e.g. "pl") aren't influenced by it because the nroff wrapper has
a quick hack which switches from UTF-8 to legacy encodings (like ISO-8859-2) for
those locales, since man pages are still encoded in non-UTF8 charsets. See the
source of /usr/bin/nroff script for details.
The problem is solved by modifying groff's font descriptions for the utf8 device
so that the standard, ASCII-compatible "0x002D" character code is used instead
of "0x2212" for the hyphen sequence ("\-").
The font settings for utf8 device are in the
/usr/share/groff/1.18.1/font/devutf8/ directory, in the files R (for regular
text), B (for bold), I and BI (for italic an bold-italic respectively).
I'm attaching a patch that does the change.
Test if the patch will apply cleanly by doing:
# cd /
# patch -p1 --dry-run < path/to/patch/devutf8_hyphen.patch
Apply the patch:
# cd /
# patch -p1 < path/to/patch/devutf8_hyphen.patch
Test by executing "man ls" and "man mount" in the en_US.UTF-8 locale. All
hyphens should me ok, you should be able to search for an option e.g. "-v".
Please, test it and, if you find it to be correct, apply and (if needed) forward
to groff maintainers (http://www.gnu.org/directory/GNU/groff.html).
[Cooker] [Bug 4212] [groff-for-man] A fix for bad man pages display on UTF-8 locales
http://qa.mandrakesoft.com/show_bug.cgi?id=4212
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
--- Additional Comments From [EMAIL PROTECTED] 2003-22-08 02:42 ---
ok, the patch is applied on
I applied it on mandoc.tmac instead of troffrc; so it only applies to man pages
and not to other uses of groff-for-man-1.19-3mdk
--
Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Reminder: ---
assigned_to: [EMAIL PROTECTED]
status: RESOLVED
creation_date:
description:
In Mandrake 9.1, there's an installer option "Use Unicode by default".
This option causes UTF-8 versions of locales to be used, which finally moves the
distribution in the direction of unifying diverse character set encoding
standards into a single, well-known and well understood encoding: UTF-8.
However, there is a problem with some UTF-8 locales with regards to man pages.
The problem exhibits itself in hyphens (e.g. in the option names) being
displayed incorrectly and being unsearchable (the "minus" character from the
keyboard doesn't match them).
This is due to the fact that the groff utility that's used for formatting pages
(when called from the nroff shell script) formats "\-" sequence in the source
input as Unicode character "0x2212", and "-" character as Unicode character
"0x2010" instead of the backward-compatible minus sign (which has code "0x002D"
for compatibility with ASCII).
The hyphen sign "0x2212" isn't handled properly by either the less viewer, or
the output terminal and as a result it's displayed with a leading garbage
character and can't be input from the keyboard when searching in the manual page
(so that e.g. it isn't possible to search for "-h" option when reading the
manual for ls).
Among others, the "en_US.UTF-8" locale is influenced by this bug. OTOH, some
other locales (e.g. "pl") aren't influenced by it because the nroff wrapper has
a quick hack which switches from UTF-8 to legacy encodings (like ISO-8859-2) for
those locales, since man pages are still encoded in non-UTF8 charsets. See the
source of /usr/bin/nroff script for details.
The problem is solved by modifying groff's font descriptions for the utf8 device
so that the standard, ASCII-compatible "0x002D" character code is used instead
of "0x2212" for the hyphen sequence ("\-").
The font settings for utf8 device are in the
/usr/share/groff/1.18.1/font/devutf8/ directory, in the files R (for regular
text), B (for bold), I and BI (for italic an bold-italic respectively).
I'm attaching a patch that does the change.
Test if the patch will apply cleanly by doing:
# cd /
# patch -p1 --dry-run < path/to/patch/devutf8_hyphen.patch
Apply the patch:
# cd /
# patch -p1 < path/to/patch/devutf8_hyphen.patch
Test by executing "man ls" and "man mount" in the en_US.UTF-8 locale. All
hyphens should me ok, you should be able to search for an option e.g. "-v".
Please, test it and, if you find it to be correct, apply and (if needed) forward
to groff maintainers (http://www.gnu.org/directory/GNU/groff.html).
[Cooker] [Bug 4282] [mdk-menu-messages] wrong menu item in "-> What to do ?" menu
http://qa.mandrakesoft.com/show_bug.cgi?id=4282 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-22-08 02:50 --- La traduction a été ajoutée, merci. (the translation has been added, thanks) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: There is no translation for the item "Add programs" in "-> What to do ?" menu, I think this menu entry is invalid. $ LC_ALL=fr_FR gettext --domain=menu-messages "Add programs" Add programs This should be remplaced in /usr/lib/menu/simplified/mandrake_desk by something similar to the Configuration/Packaging menu, that is to say : ?package(rpmdrake): command="/usr/sbin/rpmdrake" needs="x11" section="Administer your system" icon="rpmdrake.png" title="Install Software" longtitle="A graphic al front end for installing packages" Then, it's a bit better : $ LC_ALL=fr_FR gettext --domain=menu-messages "Install Software" Installer des logiciels $ LC_ALL=fr_FR gettext --domain=menu-messages "A graphical front end for installing packages" Interface graphique pour l'installation de paquetages (RPM) Thanks for this useful menu.
[Cooker] [Bug 2661] [man] hyphens and other special characters in UTF-8 mode shown as one or more control characters
http://qa.mandrakesoft.com/show_bug.cgi?id=2661 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-22-08 00:01 --- *** This bug has been marked as a duplicate of 4212 *** -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: When viewing man pages in UTF-8, all hyphens in bold text (cf. before a switch or contained in a command name) are preceeded with extra characters. In a virtual terminal, it's a quesiton mark in a circle. In gnome-terminal, there are two plain-text question marks in a row (cf. "[??-??-path]" when looking at the man page for "man"). When in en_US, the pages print fine. When in en_US.UTF-8, the problem occurs.
[Cooker] [Bug 4212] [groff-for-man] A fix for bad man pages display on UTF-8 locales
http://qa.mandrakesoft.com/show_bug.cgi?id=4212
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--- Additional Comments From [EMAIL PROTECTED] 2003-22-08 00:01 ---
*** Bug 2661 has been marked as a duplicate of this bug. ***
--
Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Reminder: ---
assigned_to: [EMAIL PROTECTED]
status: NEW
creation_date:
description:
In Mandrake 9.1, there's an installer option "Use Unicode by default".
This option causes UTF-8 versions of locales to be used, which finally moves the
distribution in the direction of unifying diverse character set encoding
standards into a single, well-known and well understood encoding: UTF-8.
However, there is a problem with some UTF-8 locales with regards to man pages.
The problem exhibits itself in hyphens (e.g. in the option names) being
displayed incorrectly and being unsearchable (the "minus" character from the
keyboard doesn't match them).
This is due to the fact that the groff utility that's used for formatting pages
(when called from the nroff shell script) formats "\-" sequence in the source
input as Unicode character "0x2212", and "-" character as Unicode character
"0x2010" instead of the backward-compatible minus sign (which has code "0x002D"
for compatibility with ASCII).
The hyphen sign "0x2212" isn't handled properly by either the less viewer, or
the output terminal and as a result it's displayed with a leading garbage
character and can't be input from the keyboard when searching in the manual page
(so that e.g. it isn't possible to search for "-h" option when reading the
manual for ls).
Among others, the "en_US.UTF-8" locale is influenced by this bug. OTOH, some
other locales (e.g. "pl") aren't influenced by it because the nroff wrapper has
a quick hack which switches from UTF-8 to legacy encodings (like ISO-8859-2) for
those locales, since man pages are still encoded in non-UTF8 charsets. See the
source of /usr/bin/nroff script for details.
The problem is solved by modifying groff's font descriptions for the utf8 device
so that the standard, ASCII-compatible "0x002D" character code is used instead
of "0x2212" for the hyphen sequence ("\-").
The font settings for utf8 device are in the
/usr/share/groff/1.18.1/font/devutf8/ directory, in the files R (for regular
text), B (for bold), I and BI (for italic an bold-italic respectively).
I'm attaching a patch that does the change.
Test if the patch will apply cleanly by doing:
# cd /
# patch -p1 --dry-run < path/to/patch/devutf8_hyphen.patch
Apply the patch:
# cd /
# patch -p1 < path/to/patch/devutf8_hyphen.patch
Test by executing "man ls" and "man mount" in the en_US.UTF-8 locale. All
hyphens should me ok, you should be able to search for an option e.g. "-v".
Please, test it and, if you find it to be correct, apply and (if needed) forward
to groff maintainers (http://www.gnu.org/directory/GNU/groff.html).
[Cooker] [Bug 3935] [menu] Garbage caracters in the menu in CH
http://qa.mandrakesoft.com/show_bug.cgi?id=3935 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-21-08 22:48 --- solved in mdk-menu-messages-9.2-2mdk -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: Two words are not good in the gnome menu and are good in the KDE menu: 1) Simplified-CH see the picture 1 for the error (GNOME) and 2 for the good spelling (KDE) 2) TR-CH see the picture log179 for the error (GNOME) and 4 for the good spelling (KDE) The second one was already reported by mail to Pablo. I add it for information.
[Cooker] [Bug 4216] [locales-he] 8bit locale missing
http://qa.mandrakesoft.com/show_bug.cgi?id=4216 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-05-08 20:57 --- done in locales-he-2.3.2-4mdk -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: ISO8859-8 missing from package. Note that some packages (like wine for example) cannot handle utf8 hebrew yet (missing keyboard layout in X). BTW: the translation of the description is not good. it should be אלו הקבצים הבסיסיים לשימוש בעברית, אתה צריך את החבילה הזאת בכדי להציג עברית של 8 ביטים, לסידור לפי האלף בית, ולהצגה נכונה של מספרים ותאריכים בהתאם ולקובל בשפה העברית. שים לב שהחבילה הזאת אינה מטפטל בהמרה מימין לשמאל או משמאל לימין, על הישום או המסוף, בין אם של X11 או המסוף וירטואלי, לעשות כן.
Re: [Cooker] Beta2: Localizations for bootsplash 'booting, press F2 for verbose' message?
Kaixo! On Mon, Aug 11, 2003 at 06:53:09PM +0200, Warly wrote: > Aleksander Adamowski <[EMAIL PROTECTED]> writes: > > > Are there plans for localizing the message at boot and shutdown (The > > "Shutting down the system... Press F2 for verbose mode" message)? > > > > How do I submit translation for my native language? > > Yes it is currenlty only translated in french, but the translation > seems to work and is under the bootsplash CVS. > > Pablo, how do contributors access po files usually? Tell me which CVS module it is, and I'll add it to the http://www.mandrakelinux.com/l10n/xx.php3 pages (with xx being the language code). > -- > Warly -- Ki ça vos våye bén, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portuguese] pgp0.pgp Description: PGP signature
[Cooker] [Bug 4280] [mdk-menu-messages] menu entry not translated
http://qa.mandrakesoft.com/show_bug.cgi?id=4280 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-05-08 21:08 --- Fixed in CVS version of menu-messages; will be included in next rebuild of mdk-menu-messages -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: The menu entry for Nautilus isn't translated, while all other Gnome entries are translated in menu Configuration/GNOME. $ LC_ALL=fr_FR gettext --domain=menu-messages "File Management" File Management $ LC_ALL=fr_FR gettext --domain=menu-messages "Change how files are managed" Change how files are managed
[Cooker] [Bug 2974] [Installation] Installation program ignore my choice of keyboard setting
http://qa.mandrakesoft.com/show_bug.cgi?id=2974 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-05-08 15:59 --- fixed in XFree86-4.3-16mdk (added recognition of "en_DK.UTF-8") -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: When i install Cooker, i choose Norwegian Keyboard layout. But later, when the settings are summarised, the setting appear to be some kind of English or US keyboard. I try to change to norwegian keyboard again, but my changes are always ignored. Workaround: After the installtaion, when the system is running, you can change keyboard layout in drakconf and then configure your X server again. And you have to pray to God that your root password is not corrupt. Curcomstances: I did an installation of current Cooker yesterday friday 7th, from ftp: //sunsite.uio.no/linux/Mandrake/Mandrake-devel/cooker/i586. The installation was done from scratch on two new PCs. I chose English Language and norwegian keyboard. The installation was done in text modus. The graphical modus did not work: A png file was not found, and in graphical modus, the installation program refused to install the packages.
[Cooker] [Bug 3340] [Installation] Belgian Keyboard
http://qa.mandrakesoft.com/show_bug.cgi?id=3340 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-05-08 16:00 --- I don't agree it is the less used. Some people may prefer other layouts, but I've always seen the belgian layout as the default keyboard when purchasing a computer in Belgium; the only non belgian keyboards I have seen are some french keyboards used in some schools, German keyboards used in the West German-speaking region, and US qwerty ones used mainly by people alredy accostumed to that layout. But the Belgian layout is clearly the most common one. In any case, you can still choose any keyboard you want at the summary step; or even after the install. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: the Belgian keyboard (azerty) is the least used in the country. (coma) Please give choice to install the other vers.(full stop) Key= Del Good work Thank you.
[Cooker] [Bug 4423] [locales-zh] Wrong format of Longdate/Shortdate in zh
http://qa.mandrakesoft.com/show_bug.cgi?id=4423 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-05-08 17:19 --- ok, it will be done on locales-zh-2.3.2-4mdk The date format sed by ls (coreutils package) and Gnome/KDE applets is usually determined by the translation file. eg, from coreutils.pot file: #: src/ls.c:644 msgid "%b %e %Y" msgstr "" #: src/ls.c:672 msgid "%b %e %H:%M" msgstr "" so, if you want to change the format, you need to translate that file (it requires the GNU disclaimer to be filled; see "The Translation project" link on the mdk status page; there is a translator for zh_CN version of coreutils; so you should contact him with suggestions for the ls date format. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: It seems that the time format of zh has not been defined within locale, because the final format is the same as US. The official date format should be as follow: Longdate: 2003?7?30 Shortdate: 2003-07-30 If you want exact date format for specific environment, just contact me.
[Cooker] [Bug 2465] [drakxtools] It is not possible to select multiple keyboard layouts
http://qa.mandrakesoft.com/show_bug.cgi?id=2465 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-04-08 23:26 --- this has been fixed in mdk 9.1 final -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: After installation with only one keyboard layout there is no way in keyboarddrake or elsewhere in kde to select multiple keyboard layouts or switch among them.
[Cooker] [Bug 491] [kdeadmin] French dictionnaries not configured
http://qa.mandrakesoft.com/show_bug.cgi?id=491 --- Additional Comments From [EMAIL PROTECTED] 2003-31-07 19:25 --- aspell-xx package is installed when choosing xx language at install time; and aspell, when called without language specific dictionnary, will select the dictionnary for the locale. So, if kde is set to use aspell by default, is there some other configuration needed ? -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: When you install in french, french dictionaries should be installed and configured by default.
[Cooker] [Bug 4447] [KDE] New: missing/misnamed kde-i18n packages
http://qa.mandrakesoft.com/show_bug.cgi?id=4447 Product: KDE Component: KDE Summary: missing/misnamed kde-i18n packages Product: KDE Version: 3.1.3-3mdk Platform: All OS/Version: All Status: UNCONFIRMED Severity: major Priority: P3 Component: KDE AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] There are missing kde-i18n-* packages if we compare what we ship with whath is available at ftp://ftp.kde.org/pub/kde/stable/3.1.3/src/kde-i18n/ The missing languages are: bs, eu, fa, hr, mk, nso, se, ss, ven, vi, zu Also, note that the chinese packages have been properly renamed to "zh_CN" and "zh_TW"; our rpm packages should do too. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 4423] [locales-zh] Wrong format of Longdate/Shortdate in zh
http://qa.mandrakesoft.com/show_bug.cgi?id=4423 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |NEEDINFO Ever Confirmed||1 --- Additional Comments From [EMAIL PROTECTED] 2003-30-07 12:06 --- locale defines three date formats: date_fmt (default date format?) d_fmt(short date format) d_t_fmt (date + hour format) you can see them with "locale -c date_fmt" (and the others) on the command line (under the choosen locale). the command "date", always use the same format by default, for the localized format you must use "date +%c" (see date --help) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEEDINFO creation_date: description: It seems that the time format of zh has not been defined within locale, because the final format is the same as US. The official date format should be as follow: Longdate: 2003?7?30 Shortdate: 2003-07-30 If you want exact date format for specific environment, just contact me.
[Cooker] [Bug 253] [pango] default pango.aliases makes GNOME2 to display Chinese fonts
http://qa.mandrakesoft.com/show_bug.cgi?id=253 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||OLD --- Additional Comments From [EMAIL PROTECTED] 2003-23-07 16:02 --- pango now uses Xft/fontconfig for font resolution -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: If I use default setting, Chinese characters will be display in different size. See screenshot in URL. In pango.aliases, chinese fonts name should be put ahead of "-*-fixed-medium-r-normal--*-*-*-*-*-*-*-*". -*-fixed-medium-r-normal--*-*-*-*-*-*-*-*,\ -kaist-iyagi-bold-r-normal--*-*-*-*-*-*-johab-1,\ -*-song ti-medium-r-normal--*-*-*-*-*-*-*-*,\
[Cooker] [Bug 3913] [aspell-nl] aspell-nl needs to be rebuild
http://qa.mandrakesoft.com/show_bug.cgi?id=3913 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-23-07 15:41 --- *** This bug has been marked as a duplicate of 1714 *** -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: When I urpmi'ed aspell-nl I got: aspell --lang=nl -c my_movie.srt Unhandled Error: The file "/usr/lib/aspell/nl.rws" is not in the proper format. Wrong Soundslike zsh: 19696 abort (core dumped) aspell --lang=nl -c my_movie.srt Rebuilding the srpm for aspell-nl fixed this problem.
[Cooker] [Bug 4024] [Installation] Taiwan and Honk Kong are listing as Country
http://qa.mandrakesoft.com/show_bug.cgi?id=4024 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-23-07 15:56 --- fixed -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: Taiwan and Honk Kong are still listing as Country. Steps to reproduce: 1. Configure a machine and use Mandrake Linux 9.1 CD to install Linux. 2. Select Tradition Chinese as OS language. 3. On the last step of installation (Conclusion), notice that on the Country, it is Taiwan and user can change it to Hong Kong too. 4. When system come to System Conclusion, on the Country part, 'Region' has been added on it, however, if click the button 'Setting'. This Setting GUI, still only have 'Country' on that. Please change Country to 'Country and Region'. There is political issue for this problem.
[Cooker] [Bug 3709] [ispell] no English dictionary for ispell
http://qa.mandrakesoft.com/show_bug.cgi?id=3709 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-23-07 15:50 --- ispell dictionnaries are being replaced with aspell ones; the only remaining ispell packages are those that haven't been converted to aspell yet. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: While installing ispell in ML9.1, rpmdrake insists on choosing one of the dictionaries, pt, ro, sl, sv, etc. English is not an option. Ispell itself is just an engine. Seems that ispell-en is missing from CDs and Web distributions.
[Cooker] [Bug 3913] [aspell-nl] aspell-nl needs to be rebuild
http://qa.mandrakesoft.com/show_bug.cgi?id=3913 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-23-07 15:24 --- the wrong aspell packages have been rebuilt and they work now in the updated pacakge -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: When I urpmi'ed aspell-nl I got: aspell --lang=nl -c my_movie.srt Unhandled Error: The file "/usr/lib/aspell/nl.rws" is not in the proper format. Wrong Soundslike zsh: 19696 abort (core dumped) aspell --lang=nl -c my_movie.srt Rebuilding the srpm for aspell-nl fixed this problem.
Re: [Cooker] gettext and libiconv.so.2
Kaiuxo! On Tue, Jul 01, 2003 at 02:38:10PM +0200, Guillaume Cottenceau wrote: > > ( gc, do you have time to upgrade gettext and libtool packages? ) > > I'm maintainer for it, but had some headaches in the past so now > I don't update to newest version anymore, I sort of expect Pablo > to do so :). Pablo, would you like becoming official maintainer > of gettext? It would be more sensible than myself I guess.. The build fails in the compilation of java version fo gettext: make[3]: Entering directory `/home/pablo/rpm/BUILD/gettext-0.12.1/gettext-runtime/intl-java' /bin/sh ../lib/javacomp.sh -d . ./gnu/gettext/GettextResource.java mv: `./gnu/gettext/GettextResource.class' et `./gnu/gettext/GettextResource.class' identifient le même fichier. make[3]: *** [gnu/gettext/GettextResource.class] Erreur 1 make[3]: Leaving directory `/home/pablo/rpm/BUILD/gettext-0.12.1/gettext-runtime/intl-java' make[2]: *** [all-recursive] Erreur 1 make[2]: Leaving directory `/home/pablo/rpm/BUILD/gettext-0.12.1/gettext-runtime' there is no "mv" command either in the Makefile or in ../lib/javacomp.sh it seems it is done by gjc... (the build also required a cange to patch7, and BuildRequires: automake1.7) -- Ki ça vos våye bén, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portuguese] pgp0.pgp Description: PGP signature
[Cooker] [Bug 2642] [XFree86] keyboard (win, menu keys)
http://qa.mandrakesoft.com/show_bug.cgi?id=2642 [EMAIL PROTECTED] changed: What|Removed |Added Component|Hardware|XFree86 Product|Hardware|XFree86 Summary|keyboard|keyboard (win, menu keys) Version|9.2-0.3mdk |4.3-4mdk --- Additional Comments From [EMAIL PROTECTED] 2003-03-07 20:56 --- Is this problem still valid? If yes, please run "xev" (it comes with X11R6-contrib package) and tell us what is reported for those keys; and also the keyboard map you are using. Run xev from an xterm (otherwise you won't see the messages). here is an exemple of what the ouput looks like when pressing the left windows key: KeyPress event, serial 25, synthetic NO, window 0x181, root 0x37, subw 0x0, time 84005365, (58,106), root:(64,132), state 0x10, keycode 115 (keysym 0xffca, F13), same_screen YES, XLookupString gives 0 bytes: "" what is interesting is the keysym sent (here, "F13"). in my case right windows sends "Multi_key" and right menu sends "Menu" Thanks -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: ASSIGNED creation_date: description: In Mandrake9.0 all the keys on my keyboard worked immediatley, including the win- and menu-key. Now the win- and menukey don't work (the rest works). They have a meaning, I checked. I jus t counted:):My keyboard has 109 keys. It is a normal win-keyboard. Not a special brand as far as I know. I choose the generic 105-driver...Maybe thi is the problem, but in Mandrake 9.0 it was ok. Some "extra"-keys on my keyboard that never worked(also not on windows...) are: Power, Wleep, Wake Up, (not suer of this one:)SysRg. It is an azerty-keyboard.
[Cooker] [Bug 2270] [menu] menudrake strips down everything after non-English character
http://qa.mandrakesoft.com/show_bug.cgi?id=2270 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2003-05-06 23:03 --- See also bug #3235 -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 3668] [Installation] All cities names is in English when user set Time Zone (Russian Install)
http://qa.mandrakesoft.com/show_bug.cgi?id=3668 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED], ||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-06-06 15:23 --- In fact the timezone names are just the raw file names and directories from /usr/share/zoneinfo/ They could maybe be translated (I put DrakX people in cc). Entries with numbers should not be translated (there is no point in translating things like "GMT+2". Also, in order to keep things simple, the list of names and translations should be kept on a separate gettext domain (so we avoid DrakX translators being mad because of yet another plentyful of translatable entries, there are 500 names; maybe countrie names coulb be moved to that extra po too). I propose calling it "mdk-place-names.po" There is a KDE po with a lot of those names already translated, so we can take them from there. The ntp_servers list could also have the country names translated (trough the same "mdk-place-names" domain). The "mdk-place-names" could also be used by other tools using place names in lists (like first time wizzard, rpmdrake (list of mirrors), etc). Instead of "mdk-place-names" we could use again the "gtk+mdk" domain, already used for some mdk specific translatable strings. The total number of translatable strings would be around 650. (400 for timezones (continents and city names) and 250 for countries and regions) In the past we already received requests to have country names centraliced in a signle po file (currently they are duplicated in both DrakX and first time wizard (and they used to be also on mdkonline); so we would be able to answer to that request at the same time too. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: ASSIGNED creation_date: description: 1. Start installation of Linux Mandrake 9.1 2. Select Russian as using language 3. See the failure when user prompted to pick a City for Time Zone
[Cooker] [Bug 4024] [Installation] Taiwan and Honk Kong are listing as Country
http://qa.mandrakesoft.com/show_bug.cgi?id=4024 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 --- Additional Comments From [EMAIL PROTECTED] 2003-06-06 14:55 --- I added the " / Region" label to use of "Country" label in help.pm; however, the word "country" appears in other parts, like "choose your country". Couldn't it be fixed in the Chinese translation instead for such cases? (which should also have the word "region" translated, it isn't currently) Chinese translations are available from http://www.mandrakesoft.com/l10n/zh_CN.php3 (for simplified Chinese) http://www.mandrakesoft.com/l10n/zh_TW.php3 (for traditional Chinese) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: Taiwan and Honk Kong are still listing as Country. Steps to reproduce: 1. Configure a machine and use Mandrake Linux 9.1 CD to install Linux. 2. Select Tradition Chinese as OS language. 3. On the last step of installation (Conclusion), notice that on the Country, it is Taiwan and user can change it to Hong Kong too. 4. When system come to System Conclusion, on the Country part, 'Region' has been added on it, however, if click the button 'Setting'. This Setting GUI, still only have 'Country' on that. Please change Country to 'Country and Region'. There is political issue for this problem.
[Cooker] [Bug 3935] [menu] Garbage caracters in the menu in CH
http://qa.mandrakesoft.com/show_bug.cgi?id=3935 --- Additional Comments From [EMAIL PROTECTED] 2003-05-06 20:41 --- Mmh, very interesting indeed. Currently (due to historical reasons) the translations are taken in the locale default encoding, then converted to utf-8 for KDE and Gnome, in order to avoid converting what is already in utf-8, the strigns are checked to see if they are valid utf-8, if yes, they are not converted. THis obvioulsy doesn't work for strings that are both utf-8 and local encoding valid byte sequences. In order to solve another bug, in menudrake (bug #2270), the way it is handled will be changed, translations will be retrieved in utf-8 always, and only converted to locale encoding when needed (not for KDE, Gnome nor ROX; on,ly for WM, icewm, etc), and as the source encoding is always known to be utf-8, no conversion surprises will happen. It should solve this bug too. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 3664] [kdebase] Pick up English on Control Center, IME will be disable.
http://qa.mandrakesoft.com/show_bug.cgi?id=3664 --- Additional Comments From [EMAIL PROTECTED] 2003-05-06 20:25 --- The language configuration should be done trough mandrake control center, not trough KDE control center, for the IME configuration to be done. Or maybe KDE should be modified so that it modifies the ~/.i18n file the same way as localedrake does (that is, not only the language variables, but also the XIM related ones) -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 3661] [Installation] Slides during instalation contains cutoff sentenses in Japanese and other asian languages
http://qa.mandrakesoft.com/show_bug.cgi?id=3661 --- Additional Comments From [EMAIL PROTECTED] 2003-05-06 17:09 --- The wordwrapping is beign done incorrectly. In the japanese slide there is place for the text, if it will be put in two lines of the same length, instead of a frist line ridiculously short, a long second line and a third line ridiculously short. The wrapping after "Linux" is incorrect; in chinese and japanese wrapping is not done at spaces (there are no spaces usually) but at any character boundary; so the firt line must be completly filled before wrapping. For the corean image, the title (on bold) is wrapped, however for text the lines can be wider (as seen in the japanese image), are the titles forced to be shorter? Imho they should be allowed to fill the whole width of the window before wrapping, it will solve that problem. Are those slides testable independently, without having to perform an actual installation? it would be helpfull to be able to test them that way. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 3658] [Installation] Keyboard Layout window shows two "Next" buttons in japanese
http://qa.mandrakesoft.com/show_bug.cgi?id=3658 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED]|[EMAIL PROTECTED] Status|ASSIGNED|NEW --- Additional Comments From [EMAIL PROTECTED] 2003-05-06 15:32 --- It probably isn't specific to Japanese but to any language showing that screen (that is, which give a choice between various keyboard layouts). The three buttons shown on the image are "Help", "Next" and "Next ->". (it should be "Help", "Advanced" and "Next ->" I suppose) I redirect to pixel and gc. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
[Cooker] [Bug 3658] [Installation] Keyboard Layout window shows two "Next" buttons in japanese
http://qa.mandrakesoft.com/show_bug.cgi?id=3658 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED]|[EMAIL PROTECTED] Status|ASSIGNED|NEW --- Additional Comments From [EMAIL PROTECTED] 2003-05-06 15:32 --- It probably isn't specific to Japanese but to any language showing that screen (that is, which give a choice between various keyboard layouts). The three buttons shown on the image are "Help", "Next" and "Next ->". (it should be "Help", "Advanced" and "Next ->" I suppose) I redirect to pixel and gc. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 3658] [Installation] Keyboard Layout window shows two "Next" buttons in japanese
http://qa.mandrakesoft.com/show_bug.cgi?id=3658 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED]|[EMAIL PROTECTED] Status|ASSIGNED|NEW --- Additional Comments From [EMAIL PROTECTED] 2003-05-06 15:32 --- It probably isn't specific to Japanese but to any language showing that screen (that is, which give a choice between various keyboard layouts). The three buttons shown on the image are "Help", "Next" and "Next ->". (it should be "Help", "Advanced" and "Next ->" I suppose) I redirect to pixel and gc. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 3658] [Installation] Keyboard Layout window shows two "Next" buttons in japanese
http://qa.mandrakesoft.com/show_bug.cgi?id=3658 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED]|[EMAIL PROTECTED] Status|ASSIGNED|NEW --- Additional Comments From [EMAIL PROTECTED] 2003-05-06 15:32 --- It probably isn't specific to Japanese but to any language showing that screen (that is, which give a choice between various keyboard layouts). The three buttons shown on the image are "Help", "Next" and "Next ->". (it should be "Help", "Advanced" and "Next ->" I suppose) I redirect to pixel and gc. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Cooker] [Bug 3658] [Installation] Keyboard Layout window shows two "Next" buttons in japanese
http://qa.mandrakesoft.com/show_bug.cgi?id=3658 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED]|[EMAIL PROTECTED] Status|ASSIGNED|NEW --- Additional Comments From [EMAIL PROTECTED] 2003-05-06 15:32 --- It probably isn't specific to Japanese but to any language showing that screen (that is, which give a choice between various keyboard layouts). The three buttons shown on the image are "Help", "Next" and "Next ->". (it should be "Help", "Advanced" and "Next ->" I suppose) I redirect to pixel and gc. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 3935] [menu] Garbage caracters in the menu in CH
http://qa.mandrakesoft.com/show_bug.cgi?id=3935 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2003-05-06 14:52 --- Could you provide me the three strings (the correct one, and the two wrong ones) in UTF-8 (an utf8 text file as attach would be ok), it will help me to find the entries in the po files. Or at lest provide the pinyin pronounciation so I can type then (I could try to type them just out of the images, by looking in various dictionnaries, but it would take me a lot of time) Thanks -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
[Cooker] [Bug 3935] [menu] Garbage caracters in the menu in CH
http://qa.mandrakesoft.com/show_bug.cgi?id=3935 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2003-05-06 14:52 --- Could you provide me the three strings (the correct one, and the two wrong ones) in UTF-8 (an utf8 text file as attach would be ok), it will help me to find the entries in the po files. Or at lest provide the pinyin pronounciation so I can type then (I could try to type them just out of the images, by looking in various dictionnaries, but it would take me a lot of time) Thanks -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 3935] [menu] Garbage caracters in the menu in CH
http://qa.mandrakesoft.com/show_bug.cgi?id=3935 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2003-05-06 14:52 --- Could you provide me the three strings (the correct one, and the two wrong ones) in UTF-8 (an utf8 text file as attach would be ok), it will help me to find the entries in the po files. Or at lest provide the pinyin pronounciation so I can type then (I could try to type them just out of the images, by looking in various dictionnaries, but it would take me a lot of time) Thanks -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 2974] [Installation] Installation program ignore my choice of keyboard setting
http://qa.mandrakesoft.com/show_bug.cgi?id=2974 --- Additional Comments From [EMAIL PROTECTED] 2003-04-04 22:40 --- Kaixo! On Fri, Apr 04, 2003 at 02:12:06PM -0500, lasse wrote: not "en_DK.UTF-8" but "en_US.UTF-8/XLC_LOCALE: en_DK.UTF-8" (the syntax is: "directory/XLC_LOCALE: localename") Because "en_US.UTF-8" is defined in that file by a line: en_US.UTF-8/XLC_LOCALE: en_US.UTF-8 (what matters is that the locale name in the right column matches your LC_CTYPE value; and that the file path in the left column exists in /usr/X11R6/lib/X11/locale/ ) There is no such thing as "danish keys". >From computer point of vue there are only charset encodings. "en_DK.UTF-8" uses UTF-8, so it can handle all letters needed by Danish language. However, as XFree86 doesn't know about "en_DK.UTF-8", then it defaults the charset encoding to "us-ascii", that is, 7nit and no accent at all. The keyboard still sends the codes of the accented letters when pressing the keys of the danbish keyboard, but as XFree86 decided it will work in 7bit us-ascii, it simply ignores everything the keyboard sends unless it is pure ascii. By adding a line: en_US.UTF-8/XLC_LOCALE: en_DK.UTF-8 You tell XFree86 that for locale "en_DK.UTF-8" it has to look at the /usr/X11R6/lib/X11/locale/en_US.UTF-8/XLC_LOCALE file, the file exist (in fact it is used by almost all UTF-8 locales); that is, it is "known" by XFree86, and it will happily accept what the keyboard sends. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: ASSIGNED creation_date: description: When i install Cooker, i choose Norwegian Keyboard layout. But later, when the settings are summarised, the setting appear to be some kind of English or US keyboard. I try to change to norwegian keyboard again, but my changes are always ignored. Workaround: After the installtaion, when the system is running, you can change keyboard layout in drakconf and then configure your X server again. And you have to pray to God that your root password is not corrupt. Curcomstances: I did an installation of current Cooker yesterday friday 7th, from ftp: //sunsite.uio.no/linux/Mandrake/Mandrake-devel/cooker/i586. The installation was done from scratch on two new PCs. I chose English Language and norwegian keyboard. The installation was done in text modus. The graphical modus did not work: A png file was not found, and in graphical modus, the installation program refused to install the packages.
[Cooker] [Bug 2974] [Installation] Installation program ignore my choice of keyboard setting
http://qa.mandrakesoft.com/show_bug.cgi?id=2974 --- Additional Comments From [EMAIL PROTECTED] 2003-04-04 13:50 --- Kaixo! Mmh... "en_DK.UTF-8" isn't recognized by XFree86... you can either edit the file /etc/X11R6/lib/X11/locale.dir and add a line: en_US.UTF-8/XLC_LOCALE: en_DK.UTF-8 Or edit your /etc/sysconfig/i18n file (or ~/.i18n ) to change "en_DK.UTF-8" with "en_US.UTF-8". (or use localedrake tool to change it to something either than English/Danmark). You can also try to just change LC_CTYPE to en_US.UTF-8, it should be enough to make XFree86 happy --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: ASSIGNED creation_date: description: When i install Cooker, i choose Norwegian Keyboard layout. But later, when the settings are summarised, the setting appear to be some kind of English or US keyboard. I try to change to norwegian keyboard again, but my changes are always ignored. Workaround: After the installtaion, when the system is running, you can change keyboard layout in drakconf and then configure your X server again. And you have to pray to God that your root password is not corrupt. Curcomstances: I did an installation of current Cooker yesterday friday 7th, from ftp: //sunsite.uio.no/linux/Mandrake/Mandrake-devel/cooker/i586. The installation was done from scratch on two new PCs. I chose English Language and norwegian keyboard. The installation was done in text modus. The graphical modus did not work: A png file was not found, and in graphical modus, the installation program refused to install the packages.
[Cooker] [Bug 3648] [Installation] No russian letters available when trying to add new user during installation
http://qa.mandrakesoft.com/show_bug.cgi?id=3648 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2003-04-04 12:10 --- During installation the keyboard is handled with old xmodmap files, not with xkb. So, the key combination to switch layouts is not yet in effect; to switch between latin/cyrillic layouts during install, use the right Ctrl key. Could you check that it works that way? (We should then add a small line to tell it on screen) --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: ASSIGNED creation_date: description: No russian letters available when trying to add new user during installation User only can use English letters even though user already went through the keyboard layout settings and set keys for switching between the languages. NOTE: User cannot use Russian letters even for Full Name. Steps to reproduce: 1. Start installation of Linux Mandrake 9.1 2. Select Russian as using language 3. Try to switch to russian keyboard when adding a new user during installation and still typing in english
[Cooker] [Bug 3647] [drakxtools] Garbage characters in MCC/Syst/DrakeBackup/Help in Simp Chinese
http://qa.mandrakesoft.com/show_bug.cgi?id=3647 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED]|[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-04-04 11:49 --- Probably the same problem again of N() being used instead of N_() and doing the actual translation in other place... Quick and dirty fix: put "ugtk2::prepare_gtk2();" at the beginning of the program. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: Garbage characters in Mandrake Control Center->System->DrakeBackup->Help. Please see attached bitmap. Steps to reproduce: 1. Install Mandrake Linux 9.1 2. Select S-CH as GUI language. 3. After installation, go to Mandrake Control Center->System->DrakeBackup->Help.
[Cooker] [Bug 2974] [Installation] Installation program ignore my choice of keyboard setting
http://qa.mandrakesoft.com/show_bug.cgi?id=2974 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2003-04-04 11:20 --- I would need to know your locale configuration (output of "locale" command). Gtk2 has a default built-in mode that is locale independent, it is limited but includes the letters used in Danish, that is why "it works". Thanks --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: ASSIGNED creation_date: description: When i install Cooker, i choose Norwegian Keyboard layout. But later, when the settings are summarised, the setting appear to be some kind of English or US keyboard. I try to change to norwegian keyboard again, but my changes are always ignored. Workaround: After the installtaion, when the system is running, you can change keyboard layout in drakconf and then configure your X server again. And you have to pray to God that your root password is not corrupt. Curcomstances: I did an installation of current Cooker yesterday friday 7th, from ftp: //sunsite.uio.no/linux/Mandrake/Mandrake-devel/cooker/i586. The installation was done from scratch on two new PCs. I chose English Language and norwegian keyboard. The installation was done in text modus. The graphical modus did not work: A png file was not found, and in graphical modus, the installation program refused to install the packages.
[Cooker] [Bug 2270] [menu] menudrake strips down everything after non-English character
http://qa.mandrakesoft.com/show_bug.cgi?id=2270 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|NEW --- Additional Comments From [EMAIL PROTECTED] 2003-04-01 16:50 --- On Tue, Apr 01, 2003 at 08:58:12AM -0500, fcrozat wrote: mendurake must write .menu files in UTF-8, it is simply easier like that; so the source encoding is known, and you can convert to other encodings if needed (for WM using locale encodign instead of UTF-8). I didn't knew .menu files told their charset; in that case, there is yet another bug: that info is not used! if the cahrset is told in .menu files, then whe ncreating the *.desktop files (that must be in utf-8) the strigns ahve to be translated from that encoding to utf-8. But there seems that the encoding of .menu files is never requested nor used. In the menu methods source strings are supposed to be in UTF-8 (that is because translations are retrieved in UTF-8). So the easiest would be to mandate UTF-8 as the only charset encoding valid for .menu files; have menudrake use UTF-8 when writting them, and have all .menu files in the rpm packages be in UTF-8 too (that should already be the case, well, they don't have any 8bit char at all it seems) And no, it won't be a problem for non-Gnome/KDE environments, as the menu files from rpm packages are already supposed to be in UTF-8 only (the menu methods creating the menu structures used by the WM already expect to work with UTF-8 as the source text). The only difference in menu methods is the charset encoding of the target (the menu structure to be created), if it is to be in the locale charset, then translate(lang,string) is used; if it is to be in utf-8, then encode_translate(lang,string,"utf-8") is used. As you can see, the source encoding is never specified, so it can only be UTF-8. At the current state of UTF-8 deployment it is much better to use UTF-8 the most possible, and only switch to another encoding at the final stage, and only if there is no other solution. That is, only when creating menu structures for WM that don't use UTF-8 but the locale charset. Remember also that UTF-8 will be more and more used (all functions allowing to draw strings antialised require strings to be in UTF-8), and also that UTF-8 will be more and more used as the default encoding. Non-UTF-8 should be handled as special exception cases, and not the opposite way. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: menudrake in mdk 9 with czech localization causes the following: when you create record or folder with nonEnglish character it creates file_xyz.desktop which is fine. the problem is that it writes something like this in it: Comment=the whole title in UTF-8 Comment[cs]=comment stripped after a non-english character example: Comment=Zábava Comment[cs]=Z and you can see only the letter Z in the menu :( the only resolution is to edit the .desktop file (in ~/.kde..) manually.
[Cooker] [Bug 3541] [evolution] Ugly Fonts
http://qa.mandrakesoft.com/show_bug.cgi?id=3541 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2003-04-01 15:36 --- You should be able to change the "variable-width" font used for printing; the fact that the font name is not displaying (it displays as empty squares) is a hint that the choosent font is probably not appropriate. For ~/.gtkrc, indeed it may be rewritten by the theme-engine (to provide a similar theme to old gtk1 programs), and in such case it is ~/.gtkrc.mine that has to be modified. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEEDINFO creation_date: description: I had recently installed Mandrake9.1 final and I get some very "ugly" fonts on the menus/folders, only the email contents which appear with the "settings" defined fonts are showing properly. This was not happening with Mandrake9.1rc1 which I was using prior to Mdk9.1. Also I didn't find this problem on any other application so far.
[Cooker] [Bug 3605] [gnumeric] fonts broken after Gnumeric upgrade
http://qa.mandrakesoft.com/show_bug.cgi?id=3605 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|UNCONFIRMED --- Additional Comments From [EMAIL PROTECTED] 2003-04-01 15:18 --- Could you put one of such fonts, and one of such gnumeric files somewhere; so we can test it? Thanks (Also, I don't understand why you have "converted" fonts?? there is no need to convert them, TTF fonts work just fine, don't they?) --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: After having upgraded Gnumeric (actually after upgrading from Mandrake 9.0 to 9.1), some files I had created with the previous Gnumeric don't display well anymore. The fonts I used in those files (these are fonts which I'd transferred from TTF files) look completely broken : character mappings seem to be corrupted (for example 'V' displays as '6', other characters display as empty squares). In fact, all fonts I had converted from Windows fonts look broken in the new Gnumeric : only Mandrake native fonts (like Luxi Sans) are OK. The same files and the same fonts look OK in OpenOffice Calc (and the fonts are OK in other programs too), thus it does not seem to be a system-wide problem. I'm uploading a screenshot. You can see a field whose content is correctly displayed in the edit box, but broken in the WYSIWYG pane.
[Cooker] [Bug 3603] [menu] menu does not respect user locale
http://qa.mandrakesoft.com/show_bug.cgi?id=3603
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||WONTFIX
--- Additional Comments From [EMAIL PROTECTED] 2003-04-01 15:13 ---
No, in lang.h are defined two variables: lang()= for those environments that
don't have real i18n for their menus; and languages()= for those environments
that do have proper i18n support for their menus (all those following the
*.dekstop standard are in such case, eg Gnome, KDE, and some others as well).
The languages()= variable lists all languages present on the system.
So, the bug is not a mdk bug, but a bug with some environments that don't allow
an i18n system-wide menu system (that is, one including several languages,
and the proper language being displayed depending on user settings).
Report the problem to WindowMaker, ICEWM, etc. projetcs, asking them to add
multilanguage support in their menu structures.
But it's not possible to provide multi-language support in the menus if the
window manager doesn't support it.
If some of those environments do support multi-language menus, but that feature
isn't handled by "update-menu", then a pointer to a document describing how the
multi-language support is done would be appreciated, so we can support it.
Thanks
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Reminder: ---
assigned_to: [EMAIL PROTECTED]
status: RESOLVED
creation_date:
description:
Menu support only system-wide l18n messages. It is not affected by users locale
setting.
Right now it is hardcoded in /etc/menu-methods/lang.h ( the language is set
during the installation stage)
Expected Results:
update-menu should respect ${HOME}/.i18n settings
[Cooker] [Bug 1713] [libpspell4] pspell 0.12.x obsolete, pspell included in new aspell
http://qa.mandrakesoft.com/show_bug.cgi?id=1713 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-03-27 17:44 --- no more packages are requiring it (other than those trhree packages requiring themselves); and the packages should be removed from cooker --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: The new aspell (0.50.x) includes its own pspell library. These old pspell 0.12.x pckages are therefore obsolete, and should be removed: libpspell4-0.12.2 libpspell4-devel-0.12.2 pspell-0.12.2 There are still some packages with dependencies to the old pspell packages, even though they use the new aspell. These dependencies should be fixed. The packages include libgtkspell0-devel (see bug 1712) and the current spec files (and source RPMs) for aspell-cy, aspell-fr, aspell-nl and aspell-uk, all requiring the obsolete pspell-devel.
[Cooker] [Bug 1394] [locales-fr] problem with french_UTF8
http://qa.mandrakesoft.com/show_bug.cgi?id=1394 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-03-27 17:36 --- *** This bug has been marked as a duplicate of 3020 *** --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: just after the install mandrake 9.1beta3, I run localedrake, and choose "France (UTF-8)" (I choose it at the beginning of the install, thanks the "advance" button). I see several problem : 1)During the boot, the messages are not displayed correctly : for example, instead of "Amorçage", I see "Amorçage" (seems like the utf-8 message is displayed like an ascii message, or an iso-8859-1 message) 2)In console mode, my french keyboard works perfectly when I'm not still logged. But, after logging, I can't use deadkeys and can't type letters like é, à or ç for example. (the keyboard seems ok in X) 3)in the X loggin window, if I try to halt or reboot, I obtain : The system is going down for system halt NOW! INIT: Switching to runlevel: 0 INIT: Sending processes the TERM signal ;2R ... and nothing ! I must press enter, and then type manually "halt" or "reboot". P.S : for information, if I'am interested in utf-8, it's because I want to use simultenaously french and esperanto, but that's an another story ;)
[Cooker] [Bug 3020] [initscripts] shutdown aborting with a bash syntax error
http://qa.mandrakesoft.com/show_bug.cgi?id=3020 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-03-27 17:36 --- *** Bug 1394 has been marked as a duplicate of this bug. *** --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: REOPENED creation_date: description: Hello, I'm using 9.1 RC2. Here's what I get when I run `shutdown -r|-h now' or `init 6' from a console session([Ctrl][Alt][F1]): ... INIT: Sending processes the TERM signal ;2R -bash: syntax error near unexpected token `;' This happens with or without ACPI set at boot time. Is there a syntax error in init scripts? Here's my hardware configuration (Keynux Agora eV laptop): 00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 11) 00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 11) 00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 42) 00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02) 00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus (rev 02) 00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio (rev 02) 00:1f.6 Modem: Intel Corp. 82801CA/CAM AC'97 Modem (rev 02) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [Radeon Mobility 9000 M9] (rev 01) 02:04.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link) 02:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 02:07.0 CardBus bridge: ENE Technology Inc CB1410 Cardbus Controller 02:0a.0 USB Controller: VIA Technologies, Inc. USB (rev 50) 02:0a.1 USB Controller: VIA Technologies, Inc. USB (rev 50) 02:0a.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51) Don't hesitate to get back to me! Thank you for your support. Cheers, Mike.
[Cooker] [Bug 3192] [XFree86] No double quotes typeable on "US International" keyboard under X
http://qa.mandrakesoft.com/show_bug.cgi?id=3192
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
--- Additional Comments From [EMAIL PROTECTED] 2003-03-27 16:44 ---
fixed in latest XFree86 package
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Reminder: ---
assigned_to: [EMAIL PROTECTED]
status: RESOLVED
creation_date:
description:
I use the "US International" keyboard and write with it in English, German, and
Portuguese. This works fine in Mandrake 9.0.
On the current Cooker (installed March 10, 2003) and also in RC1 and RC2 of
Mandrake 9.1 the "US International" keyboard (=US with deadkeys) is unusable, as
one cannot enter the double quotes ('"') (I am writing this report on an MDK 8.2
box) in X. On the text console I get them by pressing <"> at first and then
, in X nothing happens when I do this. Pressing <"> twice in X gives me
two points as they are over an 'ä' but without the 'a' under it and no double
quotes. The apostrophe key <'> works correctly, typing it followed by a space
gives an apostrophe, typing it twice gives a accent acut.
The bug is not only a problam for me, but also for many users in the US who want
to type in non-english languages.
It is probably only a small change in the keyboard tables, so it will not break
anything when it gets fixed for 9.1.
[Cooker] [Bug 2270] [menu] menudrake strips down everything after non-English character
http://qa.mandrakesoft.com/show_bug.cgi?id=2270 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|NEW --- Additional Comments From [EMAIL PROTECTED] 2003-03-27 16:38 --- It seems to be an encoding-related problem. KDE and Gnome use utf-8 for their *.desktop files (and so should other environments following *.desktop standard); environments not using *.desktop however use the locale encoding. I tried adding a menu entry, and it creates a file ~/.menu/added_by_menudrake where the added entry is. However, the entry is using locale encoding (iso-8859-2 for cs_CZ locale); it should be utf-8 (and utf-8 -> iso-8859-2 performed for WindowMaker, icewm, etc menus; but not for *.desktop that use utf-8 menudrake uses gtk2, that is, it uses utf-8 internally. So there is an utf-8 -> locale encodign being done when writting the ~/.menu/added_by_menudrake file, and that shouldn't be done. The reason why the non-language entryes (eg: Comment=...) are not truncated, while those that have language info (eg: Comment[cs]=...) are, is because, while creating the desktop files from menu definition files the non-language entries are simply copied, without anything being done about charset, while for the language ones there is a charset conversion being done from utf-8 to utf-8 (*), and as the string is not in utf-8... it fails. (*): that was because when we start with that, KDE 2.0 required utf-8, but the return of gettext() was in locale encoding, and an iconv conversion was done. After that, an ldgettext() function was used to force return of gettext to be in utf-8; and the iconv conversion was left, while completly useless... well, the finction encode_translate_func can convert to something other than utf-8, simply it only converts to utf-8 until now. So; the solution would be to: - ensure menudrake write in utf-8 in the menu definition files. - change ldgettext(), to use standard gettext and make it always return strings in utf-8 - change translate_func() (it returns the translation of the entry, in the locale encoding) so that it calls iconv() on the translated string, to convert it from utf-8 to the encoding of the locale (and no need to do lots of setenv() and setlocale() for that... just a setlocale() in main(), either the computer uses languages of the same encoding, either it uses utf-8; we no longer support mixed non-utf-8 encodings in a same system) As all strings will be in utf-8 internally, as menu won't do locale changes anymore, and as the output encoding will be utf-8 in most cases (kde and gnome), the time spent by update-menus should improve quite a lot. I attach a modified (and not tested) version of the i18n patch of menu package that does that (there is still to do the change to menudrake to ensure it writes files in utf-8). Could you take a look at the patch and see if everything is ok? --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: menudrake in mdk 9 with czech localization causes the following: when you create record or folder with nonEnglish character it creates file_xyz.desktop which is fine. the problem is that it writes something like this in it: Comment=the whole title in UTF-8 Comment[cs]=comment stripped after a non-english character example: Comment=Zábava Comment[cs]=Z and you can see only the letter Z in the menu :( the only resolution is to edit the .desktop file (in ~/.kde..) manually.
[Cooker] [Bug 2270] [menu] menudrake strips down everything after non-English character
http://qa.mandrakesoft.com/show_bug.cgi?id=2270 --- Additional Comments From [EMAIL PROTECTED] 2003-03-27 16:36 --- Created an attachment (id=400) --> (http://qa.mandrakesoft.com/attachment.cgi?id=400&action=view) changes in i18n and encodings patch (not tested) to improve i18n and charset conversion (see coment) --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEEDINFO creation_date: description: menudrake in mdk 9 with czech localization causes the following: when you create record or folder with nonEnglish character it creates file_xyz.desktop which is fine. the problem is that it writes something like this in it: Comment=the whole title in UTF-8 Comment[cs]=comment stripped after a non-english character example: Comment=Zábava Comment[cs]=Z and you can see only the letter Z in the menu :( the only resolution is to edit the .desktop file (in ~/.kde..) manually.
[Cooker] [Bug 3541] [evolution] Ugly Fonts
http://qa.mandrakesoft.com/show_bug.cgi?id=3541
--- Additional Comments From [EMAIL PROTECTED] 2003-03-26 20:50 ---
Kaixo!
On Wed, Mar 26, 2003 at 01:59:19PM -0500, Lamego wrote:
Mmh, English and Portuguese should not force use of utf-8...
maybe choice of English should be made compatible with any charset
encoding.
A better solution would be to choose, among the available X11 unicode
fonts (do "xlsfonts | gre piso10646-1" to see them) one that pleases you;
copy /etc/gtk/gtkrc.utf-8 to ~/.gtkrc, and edit it to change the
fontset value so that the choosen font is put at the beginning.
For example if you like Tahoma at size 14, install it,
then have your ~/.gtkrc have:
style "gtk-default" {
fontset = "-*-tahoma-medium-r-normal--14-*-*-*-p-*-iso10646-1,\
-*-r-*-iso10646-1,*"
}
class "GtkWidget" style "gtk-default"
The problem is that X11 font protocol assumes a font is always "complete",
it won't search for missing glyphs on other fonts (contrary to Xft that
does that); so, we are limited to some fonts with enough unicode coverage,
we can't set default utf-8 font to a font nice looking but with only
English coverage, if someone chooses utf-8 (either explicitely or
automatically) he may well want to use cyrillic, or greek, or other.
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Reminder: ---
assigned_to: [EMAIL PROTECTED]
status: NEW
creation_date:
description:
I had recently installed Mandrake9.1 final and I get some very "ugly" fonts on the
menus/folders, only the email contents which appear with the "settings" defined fonts
are showing properly. This was not happening with Mandrake9.1rc1 which I was using
prior to Mdk9.1.
Also I didn't find this problem on any other application so far.
