KDE4 proposal: Paths in i18n strings

Frans Englich englich at kde.org
Fri Jul 7 18:20:51 BST 2006

On Friday 07 July 2006 14:55, Krzysztof Lichota wrote:
> Frans Englich napisaƂ(a):
> > Even though I like the idea very much, I don't think it works. For paths
> > it works because they have natural non-QString representations(such as
> > QDir), and therefore one can overload without trouble. But if we select
> > another category, such as "identifier" instead of "path", the only types
> > are QChar/QString. So, then we end up with:
> >
> > i18n("Some string content %1", myArg);
> >
> > Should %1 be marked as an identifier or be treated regularly? No one can
> > tell. argIdentifier() is need here.
> Yes, in such case there must be something to add "meaning" to it.
> > I wonder what people include in their strings. Perhaps everything can be
> > divided into semantical categories.
> Console output, application names, URLs. Every bit of additional
> information can be used to make presentation more useful and appealing.
> URLs can be transformed into links, application names into "Run app"
> buttons, etc. :)

Yupp, that's the general idea of this. I was wondering what categories we 
should support.

- i18nUri()
	* Usage: to display URIs and file paths
	* May be a local file name or URI
	* Supported types: QUrl, KUrl, QDir, QFile
	* Visual enchancements:
	in GUI: isn't word wrapped, link created(if relative, made absolute to CWD).
	in console: colored

- i18nIdentifier()
	* Usage: to display idenifiers(may contain whitespace) such as UNIX 
usernames, language keywords
	* Supported types: QChar, QString
	* Visual enchancements:
	in GUI: fixed size, type writer font
	in console: colored

- i18nQuote()
	* Usage: to quote natural language fragments: i18n("He said: %1", 
	* Supported types: QString
	* Visual enchancement: in GUI/console: quotes the argument according to the 

What cannot/should not be divided into categories:

* Plain numbers(right?). 
* What more? I doubt all usages of arg() cannot be divided into i18nUri(), 
i18nIdentifier() and i18nQuote().

Once we've somewhat agreed/stabilized on something, I think a new k-c-d thread 
should be started summing up the purpose/problem/solution, and where kde-hci 
and kde-accessibility is CC'd in order to get their input.



More information about the kde-core-devel mailing list