[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: [otaylor@redhat.com: .desktop files and encodings]
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-02-28 20:16:54
[Download RAW message or body]

On Wednesday 28 February 2001 20:06, Owen Taylor wrote:
> David Faure <david@mandrakesoft.com> writes:
> 
> > On Wednesday 28 February 2001 18:31, Navindra Umanee wrote:
> > > 
> > > Hi, Owen sent this patch for the Desktop Entry Spec to the xdg list.
> > > I don't know enough to understand the ramifications of such a patch
> > > for KDE.  
> > > 
> > > Could someone look into it?
> > 
> > This change to the standard looks ok to me - especially if nobody expects
> > KDE to support the Legacy-Mixed encodings (strange name, we call that 
> > "locale-8-bit" :)
> 
> It's explicitly optional in the spec, because it is pretty hideous. 

Yes, and that's also why other developers (who didn't Cc you) thought that
this is probably too ugly to even be part of the SPEC at all. And I would
tend to agree with that. A spec must define a clean solution - current hacks
are another matter. And the clean solution here is UTF-8.

> Since gnome-1.4 probably won't have support for UTF-8 encoding (Sigh,
> but we don't have an XP framework for encoding conversion in a place
> we can depend on for this)
It's never too late to switch to Qt :) Sorry, couldn't resist :)

> it might be _nice_ if someone coded the
> support for Legacy-Mixed for KDE, but I certainly don't expect it. :-)
> 
> The reason why I like a name like "locale-8-bit" less is that it isn't
> a file encoded in the encoding of the locale; it is a file with
> mixed encodings that depend on the language tags. (If the current
> locale is "de_DE.utf8", the encoding of a [de] line is still
> ISO-8859-1)

Which is where this solution gets even uglier, and makes it even more difficult
to support it in KDE, since KConfig parses the whole file in one go, using
the same encoding on the stream all the way.

> 8-bit also has has some implication that multi-byte encodings aren't
> included. 
They can, if they use UTF-8, which is 8 bit too ;-)

> However, I don't care much about the name; I just wanted to
> indicate that it a) it was a mix of encodings b) its nothing that
> people should have to worry about long-term (Hence "Legacy".)

Yes - my point wasn't to argue on the name, but rather to "translate" it
to other readers :). And in fact I understand it better now.

> > The one change it means for KDE, is to add
> > Encoding=UTF-8 
> > to all the desktop files it creates.
> > Shouldn't be too hard, I'll look into that.
> > 
> > Another missing bit in KDE would be to recognize
> > Name[de_DE] and prefer it over Name[de].
> 
> That's in there - both expressed formally and with an example: [...]

I know. I said that KDE didn't support it at the moment.
All encoding considerations aside, KDE wouldn't do anything from a
Name[de_DE] entry, AFAIK. But I expect input from Stephan Kulow about this
(whether it's already supported, and whether we should add support for it).

To conclude, I think that we can add Encoding=UTF-8 in KDE to help
with encoding-determination, but this whole encoding mess might not be
a good idea for the SPEC, especially since we all know that the future
is UTF-8.

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://perso.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today

[prev in list] [next in list] [prev in thread] [next in thread]