After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 629406 - intltool-update script fails
intltool-update script fails
Status: RESOLVED WONTFIX
Product: banshee
Classification: Other
Component: general
git master
Other Linux
: Normal normal
: 1.x
Assigned To: Banshee Maintainers
Banshee Maintainers
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2010-09-12 10:12 UTC by TLE
Modified: 2020-03-17 08:51 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description TLE 2010-09-12 10:12:24 UTC
Hallo banshee devs

I just tried to integrate an updated translation of banshee, but the intltool-update script fails. It gives the following error:

xgettext: error while opening "./../src/Hyena/Hyena.Gui/Hyena.Data.Gui/Accessibility/ColumnHeaderCellTextAccessible.cs" for reading: No such file or directory
ERROR: xgettext failed to generate PO template file. Please consult
       error message above if there is any.

I think the error is that the file "./../src/Hyena/Hyena.Gui/Hyena.Data.Gui/Accessibility/ColumnHeaderCellTextAccessible.cs" which is defined in POTFILE.in no longer exist. In fact the "./../src/Hyena/" directory is entirely empty.

Regards Kenneth
Comment 1 Bertrand Lorentz 2010-09-12 17:08:45 UTC
Thank you for the bug report.

The problem is caused by the fact that the content of src/Hyena/ is in fact a git submodule. On a fresh git clone of banshee, that directory is empty.
I'm not sure what's the proper way to handle this for translations. Any advice on that is welcome.

As a workaround, you can to run the following command from the top-level banshee directory, which should fetch the files in src/Hyena/ :
git submodule update --init

This command is also run if you run the autogen.sh script.
Comment 2 TLE 2010-09-14 11:57:53 UTC
Thanks for the work around.

I *think* the proper way of handling this is a separate po-file for the submodule, but I am not at all sure. I think you should try and ask on the gnome-devel and gnome-i18n mailing lists.

Regards Kenneth
Comment 3 Claude Paroz 2010-09-16 15:32:44 UTC
Argh... submodules :-(
I've no experience with submodules, but Kenneth seems right. If it is a submodule, then it might be integrated in multiple modules. It would be a waste of time for translators to translate the same strings again and again. So the submodule should be properly i18n'ized for itself.
Comment 4 Mario Blättermann 2010-09-17 06:21:46 UTC
And what can we do for now? The hyena module doesn't include any gettext stuff, no po folder available. If it was, we could translate those strings separately. But we need a painless and proper way to let the strings appear in our "damned lies" pages. Not all translators are interested in to checkout the whole Banshee module, especially when no broadband connection is available. And run the autogen.sh script to get the missing strings... No idea how to avoid this workaround?
Comment 5 Gabriel Burt 2010-09-27 20:37:50 UTC
I agree the solution is for Hyena to have its own translations.

Mario: you can get the string-frozen (until 1.8.0) pot file here: http://banshee.fm/~gburt/tmp/banshee-1.pot
Comment 6 Alexander Kojevnikov 2010-09-27 23:28:32 UTC
I added README.l10n clarifying the situation.
Comment 7 Bertrand Lorentz 2010-10-02 15:26:08 UTC
I'm in the process of setting up proper translations for Hyena, and I'm wondering if I should copy/paste the relevant parts of all the .po files from Banshee to Hyena.

My idea is to avoid losing all of those translations for the strings that are now in the Hyena module. Is that OK with our dear translators ?
I would also bring over the file header, with relevant adjustments.

It's tedious work, but I'm willing to do it, to compensate for the trouble this issue has caused in the past weeks ;)
Comment 8 Claude Paroz 2010-10-02 17:43:11 UTC
You can simply copy all po files from banshee, then in the po directory, run 'intltool-update <lang>' for each locale. If you want to spare some kilobytes in git, delete obsolete lines at end of files before committing them (lines beginning with ~).
Comment 9 TLE 2010-10-03 10:02:50 UTC
@Bertrand

That sounds very good, thanks for your efforts.
Comment 10 Bertrand Lorentz 2010-10-31 13:46:25 UTC
I've made some progress on this issue. You can have a look at it on the following branches :

- i18n from http://gitorious.org/hyena/hyena for the changes in hyena
- hyena-i18n from http://gitorious.org/~bl8/banshee/bl8-clone for the changes necessary in Banshee's build system

I have one remaining issue :
How should the *.mo files from Hyena be installed when it is included as a git submodule ?
Currently they end up as /usr/share/locale/LG/LC_MESSAGES/hyena.mo, but that would cause file conflicts with the ones coming from the installation of a standalone Hyena package.

Does anyone know a library that has translations and is used both as a submodule and as a standalone package ?
I'd like to see how it's done...
Comment 11 Mario Blättermann 2010-10-31 14:02:27 UTC
Is it really needed to ship Hyena with Banshee by default? The better way would be to trust packagers that they build their packages with Hyena as a mandatory dependency. Then we don't get conflicts with double Hyena installations. You should uncouple Hyena from Banshee completely, if possible.
Comment 12 André Klapper 2020-03-17 08:51:27 UTC
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Please feel free to reopen this ticket (or rather transfer the project
to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the
responsibility for active development again.
See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.