Libreoffices .desktop files do not contain translation domain info

Bug #512395 reported by Gabor Kelemen on 2010-01-25
38
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Ubuntu Translations
High
Unassigned
libreoffice (Ubuntu)
Undecided
Unassigned
openoffice.org (Ubuntu)
Wishlist
Unassigned

Bug Description

The desktop files of the OpenOffice.org applications do not contain translation domain info, because there is no po-based domain to use.

The strings themselves are coming from the ooo-build package (http://cgit.freedesktop.org/ooo-build/ooo-build/tree/po), but this is currently disabled along the other OpenOffice templates - reenabling and using this could be a solution.

Another simple solution would be to use the app-install-data domain, like I proposed in bug #512380.

Gabor Kelemen (kelemeng) wrote :

Also, if we decide to use the other domain, the desktop-translations.diff file can be dropped.

Gabor Kelemen (kelemeng) wrote :

Two changes to the previous one: this does not include patching the ooo-build.pot file, as this will not be used (even if we decide to use this domain, the pot should be generated at build time...).
Also, this version removes the colon from the end of the Comment strings - there should be no colon, according to the GNOME HIG. So, if we are changing these files, let's fix that too :).

Changed in openoffice.org (Ubuntu):
assignee: nobody → Canonical Desktop Team (canonical-desktop-team)
Martin Pitt (pitti) on 2010-01-28
Changed in openoffice.org (Ubuntu):
assignee: Canonical Desktop Team (canonical-desktop-team) → Chris Cheney (ccheney)
Chris Cheney (ccheney) wrote :

Invalid per seb128 since OOo doesn't use gettext.

Changed in openoffice.org (Ubuntu):
status: New → Invalid
Gabor Kelemen (kelemeng) wrote :

Correct, OpenOffice usually does not use gettext. ooo-build does, for the .desktop files (and only for those): http://cgit.freedesktop.org/ooo-build/ooo-build/tree/po

But then, localizing these is not really possible in Ubuntu, despite the fact that they are changed: http://bazaar.launchpad.net/~openoffice-pkgs/openoffice/3.2.0-lucid/annotate/head%3A/ubuntu/desktop-templates.diff

Then, there is this bunch of po files: http://bazaar.launchpad.net/~openoffice-pkgs/openoffice/3.2.0-lucid/annotate/head%3A/ubuntu/desktop-translations.diff

from a 2 years old export of the now disabled template. This is what makes the desktop files localized somewhat - but, not dynamically, as it is for most of the other packages. It is also impossible to add new translations or change the existing ones (that's what I want, there is an ugly typo for my language).

It would be perhaps nicer to re-enable the ooo-build template (dpm: any thoughts?) and using that for X-Ubuntu-Translation-Domain, but at the end of the day, this bug is valid as hell.

Changed in openoffice.org (Ubuntu):
status: Invalid → New
Lorenzo De Liso (blackz) on 2010-03-24
tags: added: patch
Gabor Kelemen (kelemeng) wrote :

This one uses the ooo-build domain, because it's simpler this way.

Nigel Babu (nigelbabu) wrote :

Thank for the time you've taken to report this bug and providing a patch. Unfortunately, we're too late in the release cycle to get these changes into lucid (past Final Freeze). I'll milestone to later as per conversation with ccheney.

Changed in openoffice.org (Ubuntu):
importance: Undecided → Wishlist
milestone: none → later
Chris Cheney (ccheney) on 2010-05-19
Changed in openoffice.org (Ubuntu):
milestone: later → ubuntu-10.10-beta
status: New → Triaged
Changed in ubuntu-translations:
status: New → Confirmed
Chris Cheney (ccheney) on 2010-08-23
Changed in openoffice.org (Ubuntu):
assignee: Chris Cheney (ccheney) → nobody
Sebastien Bacher (seb128) wrote :

Could you explain where it would read the translations from if the openoffice or the langpacks doesn't ship gettext files to use?

tags: added: lo33

The strings on the LibreOffice .desktop files do _not_ come from libreoffice-build, they are currently generated in packaging.
Please see:
 https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/720716/comments/3

For details.

Setting status to incomplete. Please provide information on how to handle this in this case. Should there be an X-Ubuntu-Gettext-Domain entry at all and what should it be?

Changed in openoffice.org (Ubuntu):
status: Triaged → Incomplete
David Planella (dpm) wrote :

Here's some background first:

OpenOffice.org was translatable in Launchpad until a few cycles back. Translations done in Launchpad had to be exported in a tarball by clicking on the export button and then put in the package and build it with them. After some cycles where translations were never exported and put in the package due to lack of resources, we decided to disable translation of OO.o in Launchpad so that we wouldn't waste the translators effort.

So here's why there are no translatable templates for OO.o or LO (for LO we haven't even discussed translations, nor have we checked whether the package generates pot files that can be imported into LP)

And here's the proposal:

While we decide on what the best strategy for LO translations is, one thing we could do is at least make the .desktop files translatable in Launchpad. Right now they are up for translation in the wiki, which, while it works, it's a pain for both packagers and translators to maintain, and it does not allow for translations to be updated in language packs. So here's an idea:

* Add 'X-Ubuntu-Gettext-Domain=lo-desktop' to the LO .desktop files in the sources
* Modify the package to build a POT file containing the translatable messages from the .desktop files. I'd suggest having a rule in debian/rules to use intltool to build that POT file. It should match the domain name in X-Ubuntu-Gettext-Domain, so it would be called lo-desktop.pot
* Once the package would build, lo-desktop would be exposed for translation in Launchpad and would be marked for export in Language packs.
* Once the next language pack would ship, translations for the desktop files would be loaded from there.

I think we should have a session on LO translations at UDS-O as well.

Changed in openoffice.org (Ubuntu):
status: Incomplete → New
Changed in ubuntu-translations:
status: Confirmed → Triaged
importance: Undecided → High
Changed in libreoffice (Ubuntu):
assignee: nobody → Björn Michaelsen (bjoern-michaelsen)
status: New → Confirmed
Gabor Kelemen (kelemeng) on 2011-05-18
summary: - Openoffice.org's .desktop files do not contain translation domain info
+ Libreoffices .desktop files do not contain translation domain info
Gabor Kelemen (kelemeng) wrote :

One more thing is the Unity quicklist support, which was bug #720716.
These strings are added to packaging here:

http://git.debian.org/?p=pkg-openoffice/libreoffice.git;a=blob;f=patches/lp720716.diff;h=74304fe1557fcd2a7f67bb8b06c702c3c14e3795;hb=ubuntu-natty-3.3.1

According to https://wiki.ubuntu.com/Unity/LauncherAPI#Dynamic%20Quicklist%20entries these can be simply translated with marking the Name (but not UnityQuicklist - these have to be renamed!) key with an underscore, then the normal intltool process can take care of it, including dynamic translations with the X-Ubuntu-Gettext-Domain key.

After that, most of the lp720716.diff could be thrown out, which would be a good thing :).

Changed in openoffice.org (Ubuntu):
status: New → Won't Fix

[This is an automated message.]
There are no new official OpenOffice.org releases in Ubuntu packaging anymore => Won't Fix

If the problem persists, please mark this bug as "also affects project Libreoffice" or "also affects distribution Libreoffice (Ubuntu)" if that has not happened already.

Please leave references to upstream OpenOffice.org bugs in place to allow cross pollination.

Changed in openoffice.org (Ubuntu):
milestone: ubuntu-10.10-beta → none

ooo-build is dead and gone l10n-wise.

Changed in libreoffice (Ubuntu):
status: Confirmed → Won't Fix
assignee: Björn Michaelsen (bjoern-michaelsen) → nobody
Gabor Kelemen (kelemeng) on 2011-11-24
Changed in ubuntu-translations:
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers