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:[EMAIL PROTECTED] || mailto:[EMAIL PROTECTED] http://carlos.pemas.net Valencia - Spain
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
