Bug 124228 - Typos and queries re. the ppdtranslations.po file
Summary: Typos and queries re. the ppdtranslations.po file
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kdeprint
Classification: Unmaintained
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Other
: NOR normal
Target Milestone: ---
Assignee: KDEPrint Devel Mailinglist
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-25 12:59 UTC by Clytie Siddall
Modified: 2011-05-27 18:14 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Clytie Siddall 2006-03-25 12:59:16 UTC
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
Comment 1 Chris Howells 2006-05-28 03:09:58 UTC
These strings are extracted from the CUPS source code. Getting them properly fixed is unfortunately going to be hardish.
Comment 2 Marek Laane 2006-10-17 00:30:28 UTC
Then, maybe the bug report has to be forwarded to CUPS developers?
Comment 3 Marek Laane 2007-01-09 00:10:49 UTC
E.g you can post notice about the bugs to the list cups-bugs@easysw.com .
Comment 4 Michael Sweet 2007-01-26 14:20:37 UTC
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?)
Comment 5 Marek Laane 2007-02-08 00:43:22 UTC
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?
Comment 6 Kurt Pfeifle 2007-02-15 00:16:16 UTC
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)
Comment 7 Marek Laane 2007-02-17 02:22:05 UTC
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...
Comment 8 Kurt Pfeifle 2007-02-17 17:25:27 UTC
Thanks, Marek. Hints like these are very valuable.

(Reassigning bug to kdeprint in order to not let it slip through...)
Comment 9 Marek Laane 2007-08-02 23:45:04 UTC
If I'm not mistaken, 15th of March is over... :-)
Comment 10 Marek Laane 2007-09-02 00:22:01 UTC
Ping?
Comment 11 Marek Laane 2007-10-16 23:47:07 UTC
Any reaction?
Comment 12 Kurt Pfeifle 2007-10-16 23:56:47 UTC
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.
Comment 13 Kurt Pfeifle 2007-10-17 00:06:19 UTC
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.
Comment 14 Marek Laane 2007-10-18 00:32:44 UTC
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...
Comment 15 John Layt 2011-05-27 18:14:35 UTC
KDEPrint is obsolete, unmaintained and will never be revived.  Closing all open bugs.