KDE4 TODOs: Paths in i18n strings

 started: july 2006 by jstaniek, staniek@kde.org
 status: RFC, most of the topic already discussed on #kde4-devel
         with caslav.ilic@gmx.net (KLocalizedString author).
 target audience: kde-core-devel, kde-usability

The Problem

In many cases application authors need to display (relative or absolute) paths within the i18n'd messages. The path could be obtained from QDir, QFile, QFileInfo, KURL, and similar classes. In KDE3 the displaying was perfored by converting the object's path to QString and then using .arg(string) e.g. for "%1" argument of a message.

Example string:

 "Unable to open database file "xy/my
 databases/planning database.db"."

• PROBLEM1: Paths are displayed in UNIX way. To make the app feel like a native one, on win32 environment it should be converted using QDir::convertSeparators()) (TODO: what about Mac?)
• PROBLEM2: There are many ways of highlighting the path withint the message. Developers sometimes use 'pathname' (a bit geeky?), sometimes use "pathname" and sometimes use <b>pathname</b>. While it's nothing wrong in using "pathname", we need to note that in many lanuages, including Polish, it should be rather displayed as ,,pathname".
• PROBLEM3: When the path string contains spaces, sometimes is its wrapped in the way resulting in unreadable message. The possible solution could be, since we're displaying a richtext, to add <nobr>...</nobr> tags. The problem here would be that long paths will result in too wide message boxes or other GUI elements. Using "<nobr>xy/</nobr><nobr>my databases/</nobr><nobr>planning database.db</nobr>" is not an option as well asIIRC Qt's rich text seems not to break between </nobr> and <nobr> (adding spaces makes the patch look weird and not available for proper copy/paste). -- solution needed here...

The Proposal

1. Allow KURL, QFile, QDir overloads for KLocalizedString::subs(), making them acceptable in i18n() and ki18n(). Thus we'll be able to call QDir::convertSeparators() internally and add highlight the resulting path string according to KDE4 HIG. In the mockup below, the paths is additionally enclosed in <b></b> tags (using " " is an option if we agree to pick this one instead).

Posible problem: we may want to display the mesage with path to a log file or std(out|err}. The KLocalizedString class should know it's the case, so there may be aditional flag for doing this (i.e. displaying the path using " " characters only -- not as frequently used, so the default could be the rich text output).

2. Extension: allow to pass KLocalizedString object directly to KMessageBox, so it can handle path arguments in a specific way.