Bug 83222 - Avoid hard-coded line breaks in up2date messages
Summary: Avoid hard-coded line breaks in up2date messages
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: up2date
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Adrian Likins
QA Contact: Fanny Augustin
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-31 15:39 UTC by Christian Rose
Modified: 2007-04-18 16:50 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-08-27 00:32:45 UTC

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

Description Christian Rose 2003-01-31 15:39:33 UTC
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-02-01 03:16:22 UTC
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-02-01 04:48:31 UTC
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 12:55:43 UTC
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 12:56:45 UTC
Created attachment 89778 [details]
List ofe messages with hard-coded line breaks inside sentences

Comment 5 Christian Rose 2003-02-02 18:05:04 UTC
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-14 04:46:29 UTC
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 23:02:55 UTC
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.