Trouble with CSS files after creating package with translations
Hi! I recently built my first debian package, based on the 3.4.x branch from git, and with the addition of having installed translations for the Nordic languages. (I'll write up the process of doing that on the wiki, once I'm sure I have the correct steps.) I used the Perl version of build-git-snapshot provided by attachment 4007 from bug 5602 to build the packages: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5602 (I'll sign off on the patch once I see the resulting package working, I promise! ;-) After installing the package and creating a library I noticed that a couple of CSS files are missing from the OPAC when it is viewed in any language other then English, making it look weird: http://esme.priv.bibkat.no/ Firebug tells me these two files can not be found, when the language is not English: http://esme.priv.bibkat.no/opac-tmpl/prog/en/lib/yui/reset-fonts-grids.css - 404 Not Found http://esme.priv.bibkat.no/opac-tmpl/prog/en/lib/yui/skin.css - 404 Not Found But when I view the front page in English, those two files *are* found, but from a different path: http://esme.priv.bibkat.no/opac-tmpl/prog/en/css/reset-fonts-grids.css - 200 OK http://esme.priv.bibkat.no/opac-tmpl/prog/en/css/skin.css - 200 OK The contents of the css-folders for the two languages are quite different: http://esme.priv.bibkat.no/opac-tmpl/prog/en/css/ [TXT] colors.css 05-May-2011 20:59 0 [TXT] hierarchy.css 05-May-2011 20:59 1.5K [IMG] menu-button-arrow-disabled.png 22-May-2011 14:59 173 [IMG] menu-button-arrow.png 22-May-2011 14:59 173 [TXT] opac.css 22-May-2011 14:59 34K [TXT] print.css 05-May-2011 20:59 3.1K [TXT] reset-fonts-grids.css 22-May-2011 14:59 5.0K [TXT] sanop.css 05-May-2011 20:59 28K [TXT] sco.css 22-May-2011 14:59 4.0K [TXT] skin.css 22-May-2011 14:59 84K [IMG] split-button-arrow-active.png 22-May-2011 14:59 280 [IMG] split-button-arrow-disabled.png 22-May-2011 14:59 185 [IMG] split-button-arrow-focus.png 22-May-2011 14:59 185 [IMG] split-button-arrow-hover.png 22-May-2011 14:59 185 [IMG] split-button-arrow.png 22-May-2011 14:59 185 [IMG] sprite.png 22-May-2011 14:59 3.0K (The en folder in the demo on mykoha.co.nz is identical to the folder above: http://demo.mykoha.co.nz/opac-tmpl/prog/en/css/ ) http://esme.priv.bibkat.no/opac-tmpl/prog/nb-NO/css/ [TXT] colors.css 22-May-2011 08:34 0 [TXT] hierarchy.css 22-May-2011 08:34 1.5K [TXT] opac.css 22-May-2011 08:34 34K [TXT] print.css 22-May-2011 08:34 3.1K [TXT] sanop.css 22-May-2011 08:34 28K [TXT] sco.css 22-May-2011 08:34 4.0K The contents of the lib/yui directory are also different on a regular dev install: http://sksk.bibkat.no/opac-tmpl/prog/en/lib/yui/ (5 CSS files, 3 directories, 1 PNG) and a packaged install: http://esme.priv.bibkat.no/opac-tmpl/prog/en/lib/yui/ (lots of directories, no CSS, no PNG) http://demo.mykoha.co.nz/opac-tmpl/prog/en/lib/yui/ On a non-package (dev) install the contents of the corresponding folders are the same for en and nb-NO - and they are the same as the 6 files listed for nb-NO above. http://sksk.bibkat.no/opac-tmpl/prog/en/css/ http://sksk.bibkat.no/opac-tmpl/prog/nb-NO/css/ On a working non-package (dev) installation the files are taken from the en folder, where they are indeed to be found: http://sksk.bibkat.no/opac-tmpl/prog/en/lib/yui/ http://sksk.bibkat.no/opac-tmpl/prog/nb-NO/lib/yui/ On the virtual machine where I built the package, the contents of the two css-directories are also the same, and they are the 6 files listed for nb-NO above. Looks to me like the packaging/packages is doing some rearranging of the CSS files that only works for the English templates and not for templates translated into other languages? Are there any package gurus out there who are able to see what is going on? Best regards, Magnus Enger libriotech.no
Magnus Enger schreef op vr 27-05-2011 om 14:46 [+0200]:
Looks to me like the packaging/packages is doing some rearranging of the CSS files that only works for the English templates and not for templates translated into other languages? Are there any package gurus out there who are able to see what is going on?
From the debian/rules file: rm -r $(TMP)/usr/share/koha/opac/htdocs/opac-tmpl/prog/en/lib/yui ln -s /usr/share/javascript/yui $(TMP)/usr/share/koha/opac/htdocs/opac-tmpl/prog/en/lib/yui and then a bunch of installs of css and png files into ...-tmp/prog/en/css. Perhaps this is what you're seeing that causes things to lay out differently. Also, did you add in the patch on bug 6361? It won't affect this, but should make things in general work a bit better in 3.4. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
2011/5/30 Robin Sheat <robin@catalyst.net.nz>:
Magnus Enger schreef op vr 27-05-2011 om 14:46 [+0200]:
Looks to me like the packaging/packages is doing some rearranging of the CSS files that only works for the English templates and not for templates translated into other languages? Are there any package gurus out there who are able to see what is going on?
From the debian/rules file:
rm -r $(TMP)/usr/share/koha/opac/htdocs/opac-tmpl/prog/en/lib/yui ln -s /usr/share/javascript/yui $(TMP)/usr/share/koha/opac/htdocs/opac-tmpl/prog/en/lib/yui
and then a bunch of installs of css and png files into ...-tmp/prog/en/css. Perhaps this is what you're seeing that causes things to lay out differently.
Finally some time to look at this again... Yup, that is definitely the heart of the matter! Installing another language replicates lots of JS/CSS/image stuff from opac-tmpl/prog/en/ to e.g. opac-tmpl/prog/nb-NO/ and then the packaging process comes in and does it's magic, but only on the stuff in opac-tmpl/prog/en/ and not on the stuff that has been installed for any other languages. The weird thing is that it seems to work just fine for the Intranet, but not for the OPAC... I am not sure why yet. So far, these are the possibilities I can see: - Move the JS/CSS stuff out of the language specific directories and have all languages use this stuff from one and the same location. - Make debian/rules do it's stuff for all installed languages with some kind of foreach-loop, if that is possible - Find another way to handle translations than the process I am trying now (install the languages, commit the resulting files with git, build packages with build-git-snapshot) - Make custom versions of debian/rules to accommodate translations, I'm currently testing this: http://div.libriotech.no/kohadeb/rules - the packages are being built as we speak Best regards, Magnus Enger libriotech.no
On 17 June 2011 12:24, Magnus Enger <magnus@enger.priv.no> wrote:
- Make custom versions of debian/rules to accommodate translations, I'm currently testing this: http://div.libriotech.no/kohadeb/rules - the packages are being built as we speak
PS Looks like that actually worked! ;-) Magnus
Magnus Enger schreef op vr 17-06-2011 om 12:24 [+0200]:
- Find another way to handle translations than the process I am trying now (install the languages, commit the resulting files with git, build packages with build-git-snapshot)
I'd be inclined to have the rules process build the language, and then have a koha-translations-no.install file that puts the appropriate files in the right place, along with an entry to 'control' that creates a package called koha-translations-no. This way you get a package that can be installed to get -no translations. It also means I get to delegate the work of doing the first one of these (which will be the hard bit) to someone else ;) -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
2011/6/20 Robin Sheat <robin@catalyst.net.nz>:
Magnus Enger schreef op vr 17-06-2011 om 12:24 [+0200]:
- Find another way to handle translations than the process I am trying now (install the languages, commit the resulting files with git, build packages with build-git-snapshot)
I'd be inclined to have the rules process build the language, and then have a koha-translations-no.install file that puts the appropriate files in the right place, along with an entry to 'control' that creates a package called koha-translations-no. This way you get a package that can be installed to get -no translations.
That definitely sounds like the *right* solution.
It also means I get to delegate the work of doing the first one of these (which will be the hard bit) to someone else ;)
My understanding of the steps involved is severely limited, but if there is any "manual labour" involved I'd be happy to volunteer! Best regards, Magnus Enger libriotech.no
Op woensdag 22 juni 2011 20:26:12 schreef Magnus Enger:
My understanding of the steps involved is severely limited, but if there is any "manual labour" involved I'd be happy to volunteer!
Well, the guts of it is this (from memory): * The debian/rules file contains the commands that need to be run to install everything into a chroot that is needed to build all the packages (at the moment just koha and koha-common.) If the command to build the translations was added to this, along with anything needed to put them in the right place (probably alongside the en installed files), then that's the first step. * Say you've set it up to install the -no translations, then you need to add the details of that package in debian/control (or, really, debian/control.in.) This is a description and depends and so forth. Basically, it'll require a) anything that's needed to build the translations (build-depends), and b) it'll depend on koha-common to be installed. * Make sure that koha-common.install doesn't pull in the translations into the package that it makes - it should only include the default en ones (or, perhaps, they should be in their own package too. I'm not sure about that though.) * Create something like koha-translations-no.install (the name being whatever you called it in the control file) that tells it where the translated files go when the rules file is being evaluated, and where they should end up when the package is installed. All going to plan, this should work :) Once someone has worked out the tricks the first time, any other translations should just be a copy-paste of that with appropriate language codes changed. It's been on my radar for a while (I really want to get -en-nz into there for example), but I've lacked the time, and things aren't going to get quieter in the next month or three it looks like (too many libraries want Koha now apparently :) -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204
2011/6/22 Robin Sheat <robin@catalyst.net.nz>:
All going to plan, this should work :) Once someone has worked out the tricks the first time, any other translations should just be a copy-paste of that with appropriate language codes changed.
Thanks for that run-down Robin! This definitely goes on my "summer holiday cool projects" list! ;-)
It's been on my radar for a while (I really want to get -en-nz into there for example), but I've lacked the time, and things aren't going to get quieter in the next month or three it looks like (too many libraries want Koha now apparently :)
A mixed blessing? Nah, not really... ;-) Best regards, Magnus Enger libriotech.no
Hi, just a few remarks about translation packaging. On 22/06/2011 14:44, Robin Sheat wrote:
Op woensdag 22 juni 2011 20:26:12 schreef Magnus Enger:
My understanding of the steps involved is severely limited, but if there is any "manual labour" involved I'd be happy to volunteer!
Well, the guts of it is this (from memory):
* The debian/rules file contains the commands that need to be run to install everything into a chroot that is needed to build all the packages (at the moment just koha and koha-common.) If the command to build the translations was added to this, along with anything needed to put them in the right place (probably alongside the en installed files), then that's the first step. * Say you've set it up to install the -no translations, then you need to add the details of that package in debian/control (or, really, debian/control.in.) This is a description and depends and so forth. Basically, it'll require a) anything that's needed to build the translations (build-depends), and b) it'll depend on koha-common to be installed.
If you have a control.in and if generating different package language is really similar, you can auto-generate the paragraph in control. For an example, look at http://anonscm.debian.org/gitweb/?p=collab-maint/koha.git;a=tree;f=debian;hb... the file control, control.LL and rules
* Make sure that koha-common.install doesn't pull in the translations into the package that it makes - it should only include the default en ones (or, perhaps, they should be in their own package too. I'm not sure about that though.) * Create something like koha-translations-no.install (the name being whatever you called it in the control file) that tells it where the translated files go when the rules file is being evaluated, and where they should end up when the package is installed.
A 'classical' name for such packages is 'koha-l10n-XX' (see icedove, iceweasel, kde, koffice, libreoffice, ...). The install files can probably be autogenerated if the pattern is regular enough. Note that you can have a 'special' target in debian/rules to (re)generate packaging files (control, koha-l10n-XX.install, ...) that will be triggered manually by a developer when a new language must be added. But the control file *must not* be updated during a regular build of koha (with dpkg-buildpackage for examples). That would badly break the policy (and various tools at Debian if koha ended uploaded in official repo) Regards, Vincent
All going to plan, this should work :) Once someone has worked out the tricks the first time, any other translations should just be a copy-paste of that with appropriate language codes changed.
It's been on my radar for a while (I really want to get -en-nz into there for example), but I've lacked the time, and things aren't going to get quieter in the next month or three it looks like (too many libraries want Koha now apparently :)
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Vincent Danjean Adresse: Laboratoire d'Informatique de Grenoble Téléphone: +33 4 76 61 20 11 ENSIMAG - antenne de Montbonnot Fax: +33 4 76 61 20 99 ZIRST 51, avenue Jean Kuntzmann Email: Vincent.Danjean@imag.fr 38330 Montbonnot Saint Martin
Vincent Danjean schreef op wo 22-06-2011 om 16:37 [+0200]:
If you have a control.in and if generating different package language is really similar, you can auto-generate the paragraph in control. For an example, look at http://anonscm.debian.org/gitweb/?p=collab-maint/koha.git;a=tree;f=debian;hb... the file control, control.LL and rules
The templating is done with M4, so that should be possible. I'd suggest it'd be worth getting two languages in there and then extracting the stuff in common into templates.
A 'classical' name for such packages is 'koha-l10n-XX' (see icedove, iceweasel, kde, koffice, libreoffice, ...). The install files can probably be autogenerated if the pattern is regular enough.
Good point. I'd say go with l10n. I'm not sure where I got "translations" from :)
Note that you can have a 'special' target in debian/rules to (re)generate packaging files (control, koha-l10n-XX.install, ...) that will be triggered manually by a developer when a new language must be added. But the control file *must not* be updated during a regular build of koha (with dpkg-buildpackage for examples). That would badly break the policy (and various tools at Debian if koha ended uploaded in official repo)
Currently we have a couple of shell scripts in debian/ to do similar things. There's no reason we couldn't put them into the rules files though. Thanks for those comments, they're quite worthwhile. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
participants (3)
-
Magnus Enger -
Robin Sheat -
Vincent Danjean