Future of some functions in the class KCharsets

Nicolas Goutte nicolasg at snafu.de
Sun Sep 3 13:53:16 BST 2006

On Sunday 03 September 2006 12:54, Nicolas Goutte wrote:
> I am trying to improve KCharsets, especially to meet the KDE I18N policy
> and to adapt it to the reality of Qt4's QTextCodec.
> Looking at the class I have three questions:
> - the future of the entity functions (for HTML)
> - the future of KCharsets::languageForEncoding
> - the future of UTF-7 pseudo-support.
> Now to the second problem: KCharsets::languageForEncoding
> I propose to remove the function entirely. If an application adds other
> encodings top the list, it can do it directly with a full description
> including the encoding name and does not need a support from KCharsets.
> (That would be better than having "Other encoding (FOOBAR)".)
> Also an application should not be encouraged by KDE to add encodings.

I am realizing that this function cannot be dropped completely. We still need 
a function with an encoding name as parameter ("FOO") and that returns:
"long encoding description (FOO)" or "Other encoding (FOO)".

That is for example needed in KBabel where the Gettext PO file format only 
allows a narrow list of encodings (for better interoperability) but where we 
still want to show the full description to the user.

It would also be needed when using QTextCodec::availableCodecs before getting 
the encoding descriptions. (KCharsets has not such functionality yet, however 
I would like to implement, but I am not sure if it should be for KDE 4.0.)

So I suppose that the new function should be called something like: 

> Have a nice day!

More information about the kde-core-devel mailing list