Version: (using KDE Devel) Installed from: Compiled sources Compiler: gcc 4 I don't use it to translate PO files. OS: OS X ppdtranslations.po typos etc. 1. po:1118 reference: ⑤ printers.cpp:2248 flag: ⑤ no-c-format Original: ⌘0 360x360dpi, 4-bit, PostScript halftoning, weaved - weaved + woven This occurs in several other strings 2. This file is an incredibly long list of printing strings, most of which are numbers, or combinations of the same textual elements. I strongly suggest that you remove all the numbered strings from this file: there are very few languages which use other numbering systems, and if they do, they usually don't in computing. They will contact _you_. In my time translating for many OSS projects, I have never seen numbers marked for translation. I cannot believe, for example, the number of strings of the format: msgid "NUMBER dpi" or msgid "NUMBER DPI" I have translated in this file. All you need to do is: 1. Decide which way you want to write dpi/DPI then create _one_ string to translate it. You then combine the translation with any relevant number. By creating a string like this: msgid "%(type)s envelope" you create _one_ translation which can be used to describe any type of envelope. This is much more efficient, and less likely to cause translation error through sheer repetition and frustration, than marking long lists of types of envelopes for translation. So, for repeating elements (e.g. "dpi", "color", "black cartridge" and "black and colour cartridge"), you can simply mark each of these textual elements to be translated _once_, then use the results as a substitution. E.g. this string: po:1230 reference: ⑤ printers.cpp:2472 flag: ⑤ no-c-format Original: ⌘0 600x300 dpi, Best, Grayscale, Black Cartr. will become: po:1230 reference: ⑤ printers.cpp:2472 flag: ⑤ no-c-format Original: ⌘0 600x300 %(dpi)s, %(Best)s, %(Grayscale)s, %(Black Cartr)s. reusing translated textual elements, which means we translators won't be translating them over and over again in different strings. Note: please define a textual element as something you use in its entirety, separated by a comma in the strings which list these elements, so "High Quality Grayscale" does not get separated into "High Quality", and "Grayscale", because different languages have different grammatic ordering for these structures, and "High Quality" on its own is a noun, while it is used as an adjective in that textual element. In other words, it won't work if you do it that way. ;) By marking individual textual elements for translation, then using them as substitutions, you will reduce this very large and extremely repetitive file to a list of translated elements which can be re-used, and easily modified when you want to make changes. You already have some of these elements translated. Please feel free to contact me if I can help make this happen. I am unable to program, but I can advise on the language aspects. The kde-l10n-doc list can advise on the programming aspects. 3. po:1723 reference: ⑤ printers.cpp:3606 flag: ⑤ no-c-format Original: ⌘0 PrinterÕs Current Setting - PrinterÕs + Printer's There are also several strings with <Number>, like this: po:1822 reference: ⑤ printers.cpp:3822 flag: ⑤ no-c-format Original: ⌘0 Printer<27>s Current Setting which I think are also incorrect characters. po:1506 reference: ⑤ printers.cpp:3112 flag: ⑤ no-c-format Original: ⌘0 Pantone<AE> Trademark? po:1625 reference: ⑤ printers.cpp:3378 flag: ⑤ no-c-format Original: ⌘0 90<A1> I think this is supposed to be the degree symbol. There are several similar strings following this one. Some of those following strings show a crossed D in front: po:1632 reference: ⑤ printers.cpp:3392 flag: ⑤ no-c-format Original: ⌘0 Ð15<A1> which has meaning in my language, but I suspect is supposed to be a minus sign here. 4. po:1854 reference: ⑤ printers.cpp:3890 flag: ⑤ no-c-format Original: ⌘0 Job Seperator (Face Down) - Seperator + Separator Mnemonic: The "r" separates the two "a"s here. 5. po:1982 reference: ⑤ printers.cpp:4284 flag: ⑤ no-c-format Original: ⌘0 Primarily solid colors ro smooth gradients (color or gray scale) - colore ro smooth + colors or smooth 6. po:2004 reference: ⑤ printers.cpp:4392 flag: ⑤ no-c-format Original: ⌘0 Fast Res. It really helps if we can have some context. There are several words associated with printing which might be abbreviated as "Res." Please add comments to explain such strings. The more context you supply in your file, the better the translations will be. :) Here's an example: .po:2090 reference: ⑤ printers.cpp:4618 flag: ⑤ no-c-format Original: ⌘0 Group Việt: Nhóm We don't know if this is the noun "Group", or the verb "Group", as in "Group printouts". Which do we use? Usually, they won't be the same word in other languages, like (in my language): right (right and left) = phải right (right and wrong) = đúng So including context avoids incorrect translations. 7. .po:2021 reference: ⑤ printers.cpp:4448 flag: ⑤ no-c-format Original: ⌘0 Attempts to choose best PNM format for document; not always reliable. This does not make sense. Please write a sentence. This also applies to the following string. 8. You write megabyte as both "MB" and "Mb", with duplicate strings, e.g. po:2354 reference: ⑤ printers.cpp:5152 flag: ⑤ no-c-format Original: ⌘0 12 MB Printer Memory and po:2357 reference: ⑤ printers.cpp:5158 flag: ⑤ no-c-format Original: ⌘0 12 Mb Printer Memory Please choose one format and remove the other strings. You also have these two formats: .po:2578 reference: ⑤ printers.cpp:5642 flag: ⑤ no-c-format Original: ⌘0 5 MB po:2583 reference: ⑤ printers.cpp:5652 flag: ⑤ no-c-format Original: ⌘0 5MB 9. .po:2690 reference: ⑤ printers.cpp:6196 flag: ⑤ no-c-format Original: ⌘0 Black and Photo catridges - catridges + cartridges from Clytie, Vietnamese translator
These strings are extracted from the CUPS source code. Getting them properly fixed is unfortunately going to be hardish.
Then, maybe the bug report has to be forwarded to CUPS developers?
E.g you can post notice about the bugs to the list cups-bugs@easysw.com .
Um, no, those strings aren't from CUPS source code, but appear to have been collected from many PPD files (possibly to develop a message catalog to translate common PPD UI strings?)
So, is it then WONTFIX or what? Probably nobody can alert all PPD producers... Or is it possible to fix them at the KDE side?
Sorry, I only became aware of this bug report today for the first time (due to it being assigned to the "general" module. I'll try and research about its background over the next few weeks, and return with a proposal by 15th of March. Cheers, Kurt (setting timeout for this bug to March 15, 2007)
Okey. You may also see the BR 124538 (http://bugs.kde.org/show_bug.cgi?id=124538) which is maybe easier to resolve and which you might also not to be aware about because assigning to i18n not directly kdeprint...
Thanks, Marek. Hints like these are very valuable. (Reassigning bug to kdeprint in order to not let it slip through...)
If I'm not mistaken, 15th of March is over... :-)
Ping?
Any reaction?
Sorry, Marek, I didn't come round doing anything about that. Real life intervened with other things. Thanks for pinging again. I apologize for my broken promise.
I don't have any checkout from the KDE3 SVN currently, nor for KDE4. So I couldn't even commit patches that were served to me on a silver tablet... This *may* change around end of November, when my employment situation could change in a way that gives me some hardware and some time to start building KDE sources and caring for that angle again. I currently don't even know how this list of strings was compiled, and where/if at all this is used in KDEPrint for real (or is just dead code). I'll ping the current KDEPrint4 developers about it, and ask if it is used there. Would be nice if your pushing effort gets this thing fixed (should it not be dead code) for KDE4. (Even fixing it for KDE3 could still be worth while, because there may be another bugfix release coming over the next 12 months). Marek, are *you* personally willing and capable to contribute things (other than your pings and reminders to me)? If so, we could get this going more early.
To Kurt: well, I'm in some time constraint, too, but if it really helps to get things done, I could try and find some time. Clytie essentially pointed out what needs to be changed, so it probably won't take too much time, I hope... But as I understood from mail exchange there won't be any PPD translations in KDE4 anyway, so I'm not very convinced it makes sense...
KDEPrint is obsolete, unmaintained and will never be revived. Closing all open bugs.