Desktop Entry Specification

[Takao Fujiwara - Tokyo S/W Center]

I'm sorry, the mail size is exceeded.
Resending.

-------- Original Message --------

Thanks all for ideas from all of you.

  > Reducing disk space or CPU usage is not the issue here. Inconsistent
  > desktops (partially translated) is. In addittion, Supporting language
  > packs means distributors (and language teams) can provide language packs
  > *after* the software is released.

It's a great opinion. Yes, I also think so.


I compiled the merits and demerits below.

#### Option1. Change GNOME APIs.

GOOD
====
1. Don't mind 3rd party's integration into GNOME if the .desktop files are English.

2. Easily maintain and have the testings for UI messages because we can concentrate .mo files and don't need to merge base files with our ones.

3. Consist process between us and Community.


WRONG
=====
1. Community needs to accept the patches because we hardly maintain the patches internally.

2. Community don't mind to separate l10n contents if they want English messages, they can configure the parameter LC_MESSAGE=C with the user level.

3. For 1 of multilingual files; i.e. .xml file, we needs to convince each maintainer because we don't have the standard APIs for .xml translation.

4. YaST2 problem still there. [1]

[1] YaST2 is the bundled software in SuSE and it doesn't use GNOME APIs so this solution cannot be applied.


Option2. Update multilingual files with .po files

GOOD
====
1. Community does not need to change anything.

2. Easy implementation.

3. Can implement for YaST2.


WRONG
=====
1. Installation time is one hour.

2. Need to install l10n source files(.po). They are not necessary for users.

3. Need to install base source files(.desktop.in). They are not necessary for users.

4. Separate our supported 15 languages only by default. Other 72 languages are included in multilingual files of base pacakges because of the
installation time.

5. Possible installation bugs/problems and not a stable installation.

6. When add any .desktop files after install our multilingual package, it will be English message.

7. Need to add new l10n package to create multilingual files.


Option3. Update multilingual files with .mo files (Mark's suggestion)

GOOD
====
1. Acceptable installation time, 10 - 18 minutes.

2. Community does not need to have big changes for the integration but intltool only

3. Have the flexible options; Community accepts the patch, the build environment keeps the patch in the future or our l10n package has the renamed
command.

4. Have the stepped integrations after you give Go; .desktop, .icon, .keys, .server, . kbd, .schemas and etc.

5. Can implement for YaST2

WRONG
=====

1. Investigate if we can reduce the installation time.

2. Separate our supported 15 languages only by default. Other 72 languages are included in multilingual files of base packages because of the
installation time.

3. Possible installation bugs/problems and not a stable installation.

4. When add any .desktop files after install our multilingual package, it will be English message.

5. Need to add new l10n package to create multilingual files.

6. Need to confirm if the implementation does not break any specifications.


I'm also attaching the sample patch for intltool-merge. If we discuss the intltool, we may need to move into the intltool alias. But to clarify the
discussed point now, I hope it will be a reference.

I slightly changed Mark's suggestion. I thought if we can change the existent behavior with the parameters, we can update the existent build
environment with seamless.
http://lists.freedesktop.org/archives/xdg/2005-May/006911.html

Could you advise me?

Thanks,
fujiwara

Asgeir Frimannsson wrote:
 > Hi,
 >
 > Mark McLoughlin wrote:
 >
 >> Hi,
 >>
 >> On Wed, 2005-05-25 at 16:33 +1000, Asgeir Frimannsson wrote:
 >>
 >>
 >>
 >>> The main problem here is not in the translation process, but at
 >>> runtime. It is becoming more common to split up packages and ship
 >>> separate 'language packs' - Only shipping the English version of the
 >>> software, and then you get it localised by installing a language
 >>> pack. For example you ship
 >>>
 >>> myapp-1.0.rpm
 >>> and language packs:
 >>> myapp-l10n-ja-1.0.rpm
 >>> myapp-l10n-nb-1.0.rpm
 >>>
 >>> So say you're running under Japanese (ja) locale, but do not have the
 >>> Japanese language pack installed for myapp. You will still see the
 >>> content of the Desktop entry in Japanese,
 >>
 >>
 >>     So, when I discussed this with Takao before, I was very surprised
 >> that
 >> the fact that you see some Japanese translations in the ja locale when
 >> you don't have the language pack installed was considered a problem.
 >>
 >>     i.e. surely the idea of these language packs is to avoid installing
 >> unwanted translations, rather than a mechanism to disable Japanese
 >> messages in the ja locale?
 >>
 >>     If that's the case, the real bug we're trying to fix here is that
 >> when
 >> you don't have the Japanese language pack installed, some extra disk
 >> space (and memory/CPU when parsing) is used because the .desktop files
 >> contain Japanese translations.
 >>
 >>     That puts the problem in some perspective ... for me, at least.
 >>
 >>
 > Reducing disk space or CPU usage is not the issue here. Inconsistent
 > desktops (partially translated) is. In addittion, Supporting language
 > packs means distributors (and language teams) can provide language packs
 > *after* the software is released.
 >
 >>> There are two ways to implement support for this in the Desktop Entry
 >>> Spec (as said before):
 >>> 1) By adding a variable such as TranslationDomain [1]:
 >>>
 >>
 >>
 >> [snip]
 >>
 >>
 >>
 >>> 2) By having separate Desktop Entry files for translations:
 >>> - as prompted in an earlier mail by Waldo Bastian...
 >>>
 >>
 >>
 >> [snip
 >>
 >>     and
 >>
 >>  3) Use a translation tool which can merge the translations into the
 >>     .desktop files (from the message catalog) at package installation
 >>     time:
 >>
 >>  http://lists.freedesktop.org/archives/xdg/2005-May/006920.html
 >>
 >>     This doesn't require any extra support in the Desktop Entry spec
 >>     and is a pattern that could be followed for other file types
 >> like .server files, GConf schemas etc.
 >>
 >>
 >>
 > Sorry, accidentaly didn't see this mail as I read through the thread.
 > Yes, I totally agree, this approach with merging translations at
 > install-time in some way would be the most ideal and feasible approach.
 >
 > cheers,
 > asgeir