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

Hi Danilo,

Danilo Segan wrote:
> Hi Fujiwara,
>=20
> =D0=88=D1=83=D1=87=D0=B5 =D1=83 19:37, Takao Fujiwara =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0:
>=20
>=20
>>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?
>=20
>=20
> No, at least not before semantics are defined for such a behaviour.=20
> .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.
>=20
> 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_loc=
alestring, ...
I have no idea to implement that in detail but if the community would hav=
e this milestone, I hope to get anything.
Thanks, I understood the status.

>=20
>=20
>>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.
>=20
>=20
> 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 =E2=80=94 you'=
ll
> have to remove one in order to get another localization.
>=20
> 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 man=
ual.

>=20
>=20
>>I have one idea, it is that intltool-merge are invoked during
>>installations. However to implement this, I also need to install .po
>>files.
>=20
>=20
> Well, that sounds interesting, but as you point out, you'll need .po
> files to be there when running intltool-merge.
>=20
>=20
>>I would like to implement:
>>
>> - users can install C locale only.
>=20
>=20
> That's the easy one :)
>=20
>=20
>> - users can add to install l10n packages of a locale on demand.
>=20
>=20
> That's the hard one =E2=80=94 you'd need to do the following (now looki=
ng at
> .desktop files, .schemas is similar):
> =E2=80=94 use existing .desktop file as .desktop.in, with Name=3D... an=
d
>   Comment=3D... replaced by _Name=3D... and _Comment=3D...
> - 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
>=20
> 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.
>=20
> Also note that I haven't tried this with intltool, but I suspect it
> would work out fine.
>=20
> [There might also be some unexpected/undefined behaviour when there's
> already a translation to some language in .desktop file =E2=80=94 I sup=
pose
> 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 minu=
tes.
    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 pregenerate=
d cache files are installed.

  - directory structure of source tarballs.
    Currently .po files only deployed formaly in $tarball/po but multilin=
gual 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

>=20
>=20
>> - users can remove l10n packages of a locale on demand.
>=20
>=20
> 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.
>=20
> Cheers,
> Danilo