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

List:       freedesktop-xdg
Subject:    Re: Desktop Entry Specification
From:       Takao Fujiwara - Tokyo S/W Center <Takao.Fujiwara () Sun ! COM>
Date:       2005-06-08 5:16:39
Message-ID: 42A67F37.7050002 () Sun ! COM
[Download RAW message or body]



Carlos Perelló Marín wrote:
> El mar, 07-06-2005 a las 19:03 +0900, Takao Fujiwara - Tokyo S/W Center
> escribió:
> 
> [...]
> 
> 
> > I have the actual implimentation to use .mo files and I didn't notice the any \
> > performance delays on gnome-panel. I got some information to treat this.
> 
> 
> Nice to know it.
> 
> 
> > #1. Specify the domain name in .desktop
> > #2. Change .mo file name or .desktop files to have the same names.
> > #3. Use only one .mo file for .desktop files.
> > 
> > My implementation is #3. It's not so complicated against the current codes.
> 
> 
> 
> I think we should go for #1.

Thanks for the analysis.

> 
> The changes done upstream are trivial, nowadays GNOME and KDE are using
> already .po files to translate .desktop files. In fact GNOME installs
> already the translations as .mo files.
> 
> #2 is too intrusive.

Yes, You're right. However I heard a rumor about this. Now a person try sorting the \
.mo file names because the current .mo filenames are not made the  format and some \
modules are hoo.mo, some are hoo-$version.mo and others are not same as the \
application names. So I mean if there is the sorting issue which is NOT related with \
Desktop Entry, I think this option makes sense.

But if not, it's intrusive.


> 
> #3 requieres that you extract the strings from the .desktop file
> directly and create your own .po file. This solution is not intrusive at
> all, but it means that any distribution doing language packs (like SUN
> and Ubuntu, not sure if there are any others out there) will need to do
> it without reusing anything.

Also right. we have the similar situlation both are derived from the language packs \
but we need to think other situations.

One possibility is to use a environ parameters for the .mo, i.e. the default is \
specified one .mo USE_MO=hoo but it can be added as  \
USE_MO=hoo,/usr/share/locale/*/LC_MESSAGES/3rd_app

But if it is trivial to have the domain names in .desktop, we should go for #1.

Thanks,
fujiwara

> 
> 
> > > 
> > > > 2) It introduces a dependancy on GNU gettext to the desktop entry 
> > > > spec.
> > > 
> > > 
> > > Well, it's not a hard dependency, it's optional so you can ignore it if
> > > you want in your implementation.
> > 
> > I think to provide some translation options is important then the distributers \
> > can select prefered options.
> 
> 
> Indeed.
> 
> 
> > > 
> > > > 	We had several discussions about this and other related things at
> > > > GUADEC. I'll try and summarise all that in another mail.
> > > 
> > > 
> > > Yeah, please.
> > 
> > I awaited you come back from GUADEC.
> > 
> > 
> > 
> > > 
> > > > > Attached, you have the proposed change to the spec.
> > > > > 
> > > > > The diff has also a fix for the Icon type, the description of that field
> > > > > says that it should be a 'localestring' instead of just a 'string'.
> > > > 
> > > > 	I think Icon is intentionally a localestring - you might imagine an
> > > > icon having some text or a cultural reference. I don't think it would be
> > > > a good idea to have an icon like that and I haven't seen a localized
> > > > Icon key in practice but ...
> > > 
> > > 
> > > I think you misunderstood me. The spec defines Icon as a localestring
> > > but it shows it as a string so either the description or the type should
> > > be fixed.
> > 
> > We need to translate all multilingual files; .desktop, .icon, .server, .kbd and \
> > etc as the product shipment so we would like to separate all  multilungal types.
> 
> 
> Same here in Ubuntu, you are not alone (finally :-P)
> 
> Cheers.
> 
> > Thanks,
> > fujiwara
> > 
> > 
> > 
> > > 
> > > Cheers.
> > > 
> > > 
> > > 
> > > > Cheers,
> > > > Mark.
> > > > 
> > > > 
> > > > 
> > > > ------------------------------------------------------------------------
> > > > 
> > > > _______________________________________________
> > > > xdg mailing list
> > > > xdg@lists.freedesktop.org
> > > > http://lists.freedesktop.org/mailman/listinfo/xdg
> > > 
> > 
> > 
> > ------------------------------------------------------------------------
> > 
> > _______________________________________________
> > xdg mailing list
> > xdg@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/xdg
> 


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