Re: How to use "--multiple-output"

[Takao Fujiwara - Tokyo S/W Center <Takao Fujiwara Sun COM>]

Hi Danilo,

Danilo Segan wrote:
> Hi Fujiwara,
>
> Јуче у 19:37, Takao Fujiwara написа:
>
>
> > I saw gok and found this is functioned correctly about .xml.
> >
> > Is the function for .xml.in planed for other extensions;
> > .desktop.in, .schemas.in, etc?
>
>
> No, at least not before semantics are defined for such a behaviour. 
> .schemas and .desktop files are defined in such a way that all
> localizations reside in one file, so I don't see a way to allow
> --multiple-merge for them, and make that consistent and expectable.
>
> Actually, it might be possible to do the similar as with .xml files,
> but the problem is: how does one make use of those .desktop files,
> .schemas files, etc?


I'm not sure but it may need to hack some api; gnome_desktop_item_get_localestring, ...
I have no idea to implement that in detail but if the community would have this milestone, I hope to get anything.
Thanks, I understood the status.

> > As I wrote the previous mail, I need to think how to separate l10n
> > packages from packages. Now we can separate messages files by locale
> > because .mo files are deployed by locale dir. But the multilingual
> > files, .desktop, .directory, .schemas, .xml, are deployed as the
> > consolidated file, so it is difficult to separate them by locale.
>
>
> Yes, I agree.  But the problem is in the design of .desktop and
> .schemas files, not in intltool.  We can add a feature to intltool
> for it to generate .desktop files with just a subset of translations
> (or one), but you won't be able to use them concurrently — you'll
> have to remove one in order to get another localization.
>
> The problem is not simple though.  Even if FreeDesktop.org
> specification for .desktop files was changed to "merge" localizations
> from several places, there's a big problem: when somebody drags a
> .desktop file to his Desktop, and changes the Name or Comment in a
> couple of languages.  How do we handle that? It's major problem
> (permissions, creating a bunch of subdirectories, ...), and I don't
> see a straightforward solution there.

This is a good point. It is not easy way to update users' .desktop files under their home dir.
Perhaps, users need to clean up the home dirs and invoke gconftool by manual.

> > I have one idea, it is that intltool-merge are invoked during
> > installations. However to implement this, I also need to install .po
> > files.
>
>
> Well, that sounds interesting, but as you point out, you'll need .po
> files to be there when running intltool-merge.
>
>
> > I would like to implement:
> >
> > - users can install C locale only.
>
>
> That's the easy one :)
>
>
> > - users can add to install l10n packages of a locale on demand.
>
>
> That's the hard one — you'd need to do the following (now looking at
> .desktop files, .schemas is similar):
> — use existing .desktop file as .desktop.in, with Name=... and
>   Comment=... replaced by _Name=... and _Comment=...
> - run intltool-merge on it with the single .po file for the locale
>   you're adding to it, thus producing new .desktop file with this one
>   translation added
>
> So, it might be possible to create a l10n package which would contain
> only single set of PO files (set for one language), but you'd need to
> know the exact path of each installed .desktop file, so you could
> reuse it as .desktop.in.
>
> Also note that I haven't tried this with intltool, but I suspect it
> would work out fine.
>
> [There might also be some unexpected/undefined behaviour when there's
> already a translation to some language in .desktop file — I suppose
> intltool-merge would add another translation there, though I haven't
> looked at it, and it's hard to see which one would get used]

Yes, You are right.
I suppose .desktop.in files are also installed.

/usr/share/locale/$lang/LC_MESSAGES/*.mo
/usr/share/po/$modules/$lang.po
/usr/share/po/$modules/.intltool-merge-cache
/usr/share/applications/*.desktop
/usr/share/applications.in/*.desktop.in
/usr/share/gnome/vfolders/*.directory
/usr/share/gnome/vfolders.in/*.directory.in
/usr/share/control-center-2.0/capplets/*.desktop
/usr/share/control-center-2.0/capplets.in/*.desktop.in
/usr/lib/bonobo/servers/*.server
/usr/lib/bonobo/servers.in/*.server.in
/etc/gconf/schemas/*.schemas
/etc/gconf/schemas.in/*.schemas.in
/usr/share/icons/$theme/index.theme
/usr/share/icons/$theme/index.theme.in
/usr/share/icons/$theme/48x48/emblems/*.icon
/usr/share/icons/$theme/48x48/emblems.in/*.icon.in
/usr/share/gnome-about/gnome-version.xml
/usr/share/gnome-about/gnome-version.xml.in
/usr/share/yelp/toc.xml
/usr/share/yelp/toc.xml.in
....

I also suppose all multilingual files are generated by .in and .po files.

1. Install necessary l10n packages of .mo files.
2. Check what locale dirs are created in /usr/share/locale.
3. Install .in and .po files of installed locales as same as .mo.
4. Invoke intltool-merge


This is an idea to install l10n packages.

>> - users can add to install l10n packages of a locale on demand.
>> - users can remove l10n packages of a locale on demand.


But I need to think some points.

 - installation time.
   If invoke intltool-merge during installation, it may take max 30 minutes.
   This will affects all users even if users install C locale only. But if users install
   all locales, it will be faster then C locale only because pregenerated cache files are installed.

 - directory structure of source tarballs.
   Currently .po files only deployed formaly in $tarball/po but multilingual files are at random; data dir, src dir, ...
   so it is difficult to pick up them automatically.


How about this?
If somebody comments this, I'm glad.

Thanks,
fujiwara

> > - users can remove l10n packages of a locale on demand.
>
>
> Removing translations from .desktop and .schemas files shouldn't be
> too hard, IMHO, but you'd need to write a separate tool to do that.
>
> Cheers,
> Danilo