Future of some functions in the class KCharsets

[Nicolas Goutte]

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: 
KCharsets::descriptionForEncoding

>
>
[...]
>
> Have a nice day!