Bug 83222 - Avoid hard-coded line breaks in up2date messages
Avoid hard-coded line breaks in up2date messages
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: up2date (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Fanny Augustin
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-31 10:39 EST by Christian Rose
Modified: 2007-04-18 12:50 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-26 20:32:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
List ofe messages with hard-coded line breaks inside sentences (5.90 KB, text/plain)
2003-02-02 07:56 EST, Christian Rose
no flags Details

  None (edit)
Description Christian Rose 2003-01-31 10:39:33 EST
Almost all messages in up2date include hard-coded line breaks ("\n"). These are
bad both for localization and accessibility. Below is the rationale:

---
Avoid hard-coded line breaks whenever possible in text that is to be shown with
variable width fonts, if you can use a toolkit that allows for automatic line
wrapping, such as GTK+. In other words, don't do it like this:

   message = _("GFoo is an excellent frobnicator\n"
               "application that supports many\n"
               "different frobnicators. It was\n"
               "written by F. Foo and B. Bar\n"
               "with help from B. Baz.");
   

Instead, use automatic line wrapping and make the message have no line breaks:

   message = _("GFoo is an excellent frobnicator "
               "application that supports many "
               "different frobnicators. It was "
               "written by F. Foo and B. Bar "
               "with help from B. Baz.");
   

The reasons for this is that making the lines have the appropriate width with
some variable-width font that is different from the one used when editing is not
only a difficult task for the developer, it's also a very difficult task for all
translators. Also, the danger of line breaks "moving around" when the developer
changes the hard-coded wrapping (and thus all translations needing updates) is
eliminated when line breaks are removed.

Automatic line wrapping is also very useful for users that need accessibility
and other users that want to use different fonts or bigger fonts.
---

Please consider using automatic line wrapping where possible.
Comment 1 Adrian Likins 2003-01-31 22:16:22 EST
Okay, extraneous new lines cleaned up... at least 
some of them.

This changes alot of strings though...

in 3.1.10...
Comment 2 Adrian Likins 2003-01-31 23:48:31 EST
on second thought, maybe not... 

seems to break the heck out the current makefiles for 
generate po files... 

investigating what causing the breakage...
Comment 3 Christian Rose 2003-02-02 07:55:43 EST
I'm attaching a list of messages (from the current pot file) that has hard-coded
line breaks inside sentences.
Comment 4 Christian Rose 2003-02-02 07:56:45 EST
Created attachment 89778 [details]
List ofe messages with hard-coded line breaks inside sentences
Comment 5 Christian Rose 2003-02-02 13:05:04 EST
An additional note is that many messages currently are identical between the GUI
version and the TUI version, with the exception of the added hard-coded line
breaks in the GUI versions of the messages.

This means that there are two copies of almost all messages, one with the
hard-coded line breaks and one without, and thus the work is doubled for all
translators. If the GUI versions of the messages were standardized to not use
hard-coded line breaks like the TUI versions, this would dramatically reduce the
needed work from translators, since message translations can be re-used between
the TUI and GUI versions. And if the TUI versions of the messages are already
translated, there is no need to update at all.
Comment 6 Jay Turner 2003-02-13 23:46:29 EST
Bouncing this back to assigned, as there appears to still be some issues related
to line breaking and consolidating the TUI and GUI messaging.
Comment 7 Adrian Likins 2003-08-06 19:02:55 EDT
Had another stab at this. Changes should  lane on elvis soon.

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