Bug 107204 - Horrible string concatenations terribly broken for I18N in rhpl
Horrible string concatenations terribly broken for I18N in rhpl
Product: Fedora
Classification: Fedora
Component: rhpl (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Depends On:
  Show dependency treegraph
Reported: 2003-10-15 15:39 EDT by Christian Rose
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-10-15 15:47:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Christian Rose 2003-10-15 15:39:21 EDT
Tested with Swedish as the language in Fedore Core Test 3.

In the mouse model list of the mouse configuration screen in anaconda graphical
install, I see these entries:

"Mouse Systems Mus (seriell)"
"Nej Mouse"
"Sun Mus"

This is worse than a Babelfish translation gone horribly wrong!
The correct Swedish wordings should be:

"Mouse Systems-mus (seriell)"
"Ingen mus"

Since I've translated both anaconda and rhpl myself I know that I didn't
translate these messages like this, and both the anaconda and rhpl sv.po files
confirm this. Instead it seems there is some horrible string concatenation going
on in the code.
String concatenations in code like this is horribly broken for translation for a
multitude of reasons, you can read about many of them at

Please allow for translation of the *full* sentences instead, ie the actual
messages, instead of just parts of them and gluing them together later.
Comment 1 Jeremy Katz 2003-10-15 15:47:19 EDT
This is just mouse vendor mouse model.  They're completely separate entities. 
We only shove them together in text mode because we can't do a nice tree like in
the graphical mode due to the fact that newt is fairly primitive as a toolkit.

With the move to 2.6, maybe I can just basically throw this out as mice will all
multiplex through /dev/input/mice (except for serial mice, but they can be
handled as the special case instead of the norm) at which point all of these
random crap mouse names can go away ;)

Note You need to log in before you can comment on or make changes to this bug.