Re: [Translation-i18n] Independent resolution of catalog paths

[Bruno H. <br...@cl...>]

Hello Часлав,

> > There are
> > two clean solutions: [...] you change the file format so that every
> > translation of such a file is stored in a separate file. [...]
> 
> This is what we're aiming for -- updating the .desktop file spec. ...
> come up with a solution that could in principle be applied to any kind of
> data files where installers and readers are unrelated. I'd like to take the
> wide approach.

I'm convinced this route leads to complexity, intransparency, and inefficiency.
And it does not solve the bigger problem that installers like rpm cannot cope
with contributions to files.

As an example of the bigger problem: Suppose 10 different packages want to
offer to the user the same customization, in a file /usr/share/config.charset
(in my case). The idea is simple and convenient for the user. But no, the
distributors forced me to remove this customization, because it did not
fit into their "every file is owned by only one package" paradigm.

The route of changing the spec of .desktop files leads to complexity.
Up to now it was easy to copy a .desktop file and to make it available to
another package. Or to add an extra translation by changing a line. Your
proposal goes into the opposite direction.

The route of changing the spec of .desktop files leads to intransparency.
When the user gets a buggy translation on his screen for a .desktop file,
he has to start searching around where it came from.

The route of changing the spec of .desktop files leads to inefficiency.
Instead of doing 1 open() system call, it will have to do half a dozen
open() calls, in order to find the appropriate translation.

Also ask yourself: How frequent is it for a program to be run vs. to be
installed or updated? Does this justify optimizing a file format for the
installation rather than for runtime?

Really bad.

The better route is to teach the installers to install _contributions_
to a file. A contribution is an abstract concept, that is implemented
differently for the different file types. It supports 3 operations:
  - Adding the contribution ("install").
  - Removing the contribution ("uninstall").
  - Testing the presence of the contribution ("query").

> That's why right now everyone is thinking in the direction of many .desktop
> files being covered with a single catalog (e.g. for a standalone
> application, its main UI catalog).

This is bad, because it prevents copying a .desktop file as a single entity.

> Just got another idea. ...
> Then, the package install into this common prefix the file foodomain.basedir,
> containing only the absolute path to base directory, where
> LANG/LC_MESSAGES/foodomain.mo files reside:
> 
>   /somewhere/or/elsewhere/locale

What is the use-case where this extra indirection has a benefit? Why can't it
install the .mo files directly under /usr/share?

Bruno