Language packs and desktop entries

[Carlos Perelló Marín]

El mar, 07-06-2005 a las 15:21 +0200, Joerg Barfurth escribió:
> Hi,
> 

Hi

> Carlos Perelló Marín wrote:
> > El mar, 07-06-2005 a las 12:02 +0100, Mark McLoughlin escribió:
> >
> 
> >>	To summarise the discussion we had at GUADEC around this issue, we
> >>talked about two solutions.
> >>
> >>  1) Put the translation domain for the app in the .desktop file and
> >>     have .desktop file parsers pull the translations from the 
> >>     approriate message catalog.
> >>
> 
> >>  2) The install-time merging of translations into the .desktop file.
> >>
> 
> > As I said in my previous mails, I see a third option:
> > 
> > 3) Add the translation domain info to the .desktop files and let the
> > implementator decide if they want to stay as we handle translations
> > today or use 1) or 2). That's the point behind a spec, it does not
> > drives the way the implementation is done.
> > 
> 
> But the point of a spec is also to specify how certain things are and
> should be handled. Specifying N different ways to handle the same
> problem and suggesting to make it all configurable is not the point of a
> spec.

It's not really to handle the same problem, current spec works with
static releases that don't get any translation post release, that extra
field lets you add translations later, after the release.

> 
> If the spec includes 1), then any tool, application or library that
> parses desktop files and that is written to the spec needs to include
> this capability.

Why?

It's a method that lets you expand/update translations available on
release time that's all. If you want that your implementation supports
it, go for it, if you want a more conservative approach, use that field
and update the .desktop files with the make install rule...

> 
> The capability to handle the existing localestrings mechanism would also
> be needed to support older apps. For that scenario you'd also have to
> define what happens when both are present.

As I said before, It's a complement never a substitute of current
localestrings... localestrings should be used as a fallback in case you
implement it using the .mo files on runtime, I never asked for its
removal, they should be there.

> 
> A spec also tells developers how to address certain issues. With your
> proposal, where should I put my localized .desktop strings as
> application author? Into the .desktop files my package installs? Into
> .mo-Files so they can be packaged as language packs? Into both?

It depends on the maintainer, he does not need to change the way they do
it atm. Language packs are handled by third parties and I don't think we
should move that complexity into upstream, yes, define a way to do
language packs and people following an specific way to do it could do
our life easier, but that's more difficult to achieve. Instead of that
I'm saying: 'Do whatever you have been doing until today, only add this
extra information to the .desktop files so we can handle updates easier'

This relays on the current method to handle translations, we need it, I
don't want to kill it, I want to expand it.

> 
> Please consider that desktops also are a platform for thrid-party
> developers. Even as a distributor you don't have access to the source or
> packaging scripts for all software that will be installed on your desktop.

Right, but that's not an issue as current system will be valid, and they
don't need to use language packs to be able to update translations post
release, the system will work as it works today. Where is the problem?

Cheers.

> 
> Ciaso, Joerg
> 
-- 
Carlos Perelló Marín
Ubuntu Hoary (PowerPC)  => http://www.ubuntulinux.org
Linux Registered User #121232
mailto:carlos at pemas.net || mailto:carlos at gnome.org
http://carlos.pemas.net
Valencia - Spain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050607/d9ca7421/attachment.pgp