Re: How to use "--multiple-output"
Danilo Segan <[email protected]> Sun, 04 Jul 2004 14:22:53 +0200
| Newsgroups | gmane.comp.freedesktop.intltool,gmane.comp.gnome.lib.xml.internationalization |
|---|---|
| Message-ID | <[email protected]> |
Hi Fujiwara, =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: > 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.=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. 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? > 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 =E2=80=94 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. > 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 =E2=80=94 you'd need to do the following (now looking at .desktop files, .schemas is similar): =E2=80=94 use existing .desktop file as .desktop.in, with Name=3D... and 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 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 =E2=80=94 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] > - 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