helpGNU gettext - Support: sr #108887, Icon= in .desktop files

 
 

sr #108887: Icon= in .desktop files

Submitted by:  Piotr Drąg <piotrdrag>
Submitted on:  Sun 20 Sep 2015 11:00:43 AM UTC  
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Operating System:  None

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Wed 26 Jun 2019 03:26:10 PM UTC, comment #14: 

By the way, it is already possible to stop extracting Icon from the xgettext/msgfmt command line:

xgettext -o - -k -kName -kGenericName -kComment -kKeywords a.desktop

Note that the first -k is without argument.

Daiki Ueno <ueno>
Project Administrator
Wed 26 Jun 2019 10:34:12 AM UTC, comment #13: 

I wasn't aware of this; indeed let's stick to the existing framework then. So something along the lines of:

# xgettext: notranslate (or noextract, skip, ignore, whatever...)
Icon=foo

Egmont Koblinger <egmont>
Wed 26 Jun 2019 09:47:25 AM UTC, comment #12: 

> May I recommend to go with annotations on the preceding line, such as
>
>    # @notranslate
>    Icon=foo


Yes this sounds like a good idea.  As we already have the 'xgettext:' special comment for syntax checking, that can be implemented by extending the syntax:
https://www.gnu.org/software/gettext/manual/html_node/xgettext-Invocation.html#xgettext-Invocation

Daiki Ueno <ueno>
Project Administrator
Wed 26 Jun 2019 08:48:04 AM UTC, comment #11: 

> Maybe a different solution would be to make translating the Icon key opt-in? So by default it’s skipped when extracting strings, but the developer can decide to have it translatable in the rare cases where it is needed.


May I recommend to go with annotations on the preceding line, such as

    # @notranslate
    Icon=foo

I'd personally prefer to keep it default translateable, thus opt-out. This way developers "just" need to add this line to hundreds of apps, but there's no risk of temporary breakages. Also one doesn't have to remember which keys default to which behavior (fewer surprises).

I'm not against a default-off opt-in behavior either (e.g. @translate above Icon=) for certain keys including Icon, but be aware that there's a risk of temporarily breaking apps that do use localized icons. At least it would be nice if you could get a list of such apps and send them an FYI to update their software before gettext gets updated.

Egmont Koblinger <egmont>
Wed 26 Jun 2019 08:44:23 AM UTC, comment #10: 

> > - Icons may need to be mirrored for right-to-left locales.
> This seems like something concerning icons in UI more than application icons.


Terminal emulators often have an icon like ">_". If one day there'll be a fully RTL terminal emulator experience (I'm working on part of this story right now), it might be reasonable to have an icon of "_<".

> > - Icons may contain text strings (a bad practice, but anyway).


A valid case for this could be a font editor or font picker app, having an icon showing "Aa" in English, but some local characters for other scripts.

Egmont Koblinger <egmont>
Wed 26 Jun 2019 08:33:12 AM UTC, comment #9: 
Egmont Koblinger <egmont>
Sat 27 Oct 2018 05:01:57 PM UTC, comment #8: 

> Would it help if msgfmt, in Desktop Entry mode, would verify that translations of 'Icon' values point to existing files? To this effect, msgfmt would need to have option that specifies a list of directories, in which to search for the icons.


It would help, but I’m not sure how it’s feasible. Some .desktop files use icons available in the system (e.g. accessories-calculator), others have icons distributed with the package (e.g. org.gnome.Calculator). The former probably depends on the system/distribution, the latter can vary between packages.

Maybe a different solution would be to make translating the Icon key opt-in? So by default it’s skipped when extracting strings, but the developer can decide to have it translatable in the rare cases where it is needed.

Piotr Drąg <piotrdrag>
Sat 27 Oct 2018 11:44:01 AM UTC, comment #7: 

> Every release someone (developer, maintainer, or usually me) has to manually fix numerous translations to not point to non-existent files.


Would it help if msgfmt, in Desktop Entry mode, would verify that translations of 'Icon' values point to existing files? To this effect, msgfmt would need to have option that specifies a list of directories, in which to search for the icons.

Bruno Haible <haible>
Project Administrator
Fri 26 Oct 2018 06:50:23 PM UTC, comment #6: 

> Icons are generally considered as locale-dependent for three reasons:
> - Icons may contain signs that are considered rude in some cultures.


I would argue those icons should be avoided altogether.

> - Icons may need to be mirrored for right-to-left locales.


This seems like something concerning icons in UI more than application icons.

> - Icons may contain text strings (a bad practice, but anyway).


Same as the first one.

> So, the question should rather be: What is the problem that it causes to translators? If the icon is fine, translators can just leave the original value in place, no?


We started adding a comment to every .desktop file in GNOME asking translators to copy the string instead of translating it, and while it seems to have lowered the amount of incorrectly “translated” icons, it has not stopped them. Every release someone (developer, maintainer, or usually me) has to manually fix numerous translations to not point to non-existent files.

Piotr Drąg <piotrdrag>
Fri 26 Oct 2018 06:31:49 PM UTC, comment #5: 

> I have never seen a locale-dependent icon.


Icons are generally considered as locale-dependent for three reasons:
- Icons may contain signs that are considered rude in some cultures.
- Icons may need to be mirrored for right-to-left locales.
- Icons may contain text strings (a bad practice, but anyway).

More on this at https://www-01.ibm.com/software/globalization/guidelines/a8.html

So, the question should rather be: What is the problem that it causes to translators? If the icon is fine, translators can just leave the original value in place, no?

Bruno Haible <haible>
Project Administrator
Wed 23 Sep 2015 12:14:50 PM UTC, comment #4: 

> Sorry, I can't judge without confirming it with the people behind the spec. Maybe we could ask on the xdg list?


Could you please do it? I don't think I'm subscribed.

> That's because with intltool maintainers manually mark translatable keys with "_", no?


Right, of course.

Piotr Drąg <piotrdrag>
Wed 23 Sep 2015 05:07:39 AM UTC, comment #3: 

> I have never seen a locale-dependent icon.


Sorry, I can't judge without confirming it with the people behind the spec.  Maybe we could ask on the xdg list?

> The previous tool used to translate .desktop files (intltool) didn't extract the Icon key.


That's because with intltool maintainers manually mark translatable keys with "_", no?

Daiki Ueno <ueno>
Project Administrator
Mon 21 Sep 2015 09:41:39 AM UTC, comment #2: 

I have never seen a locale-dependent icon. The previous tool used to translate .desktop files (intltool) didn't extract the Icon key. As it stands now, it's just a potential point of failure for translators.

Piotr Drąg <piotrdrag>
Sun 20 Sep 2015 11:58:22 PM UTC, comment #1: 

According to the specification, the Icon key is really translatable:
http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html

Maybe it is to allow applications to have locale-dependent icons?

Daiki Ueno <ueno>
Project Administrator
Sun 20 Sep 2015 11:00:43 AM UTC, original submission:  

xgettext extracts "Icon=" lines from .desktop files, which it shouldn't do.

Piotr Drąg <piotrdrag>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by egmont (Posted a comment)
  • -email is unavailable- added by haible (Posted a comment)
  • -email is unavailable- added by ueno (Posted a comment)
  • -email is unavailable- added by piotrdrag (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    No changes have been made to this item

    Back to the top


    Powered by Savane 3.5