Editing extra translation info is inconsistent with sidebar

[luebbe]

The weblate sidebar shows explanation, labels and tags as being editable, but tags listed in the side bar are not shown in the dialogue.

Expected behavior

See attached screenshot, "c-format" tag:

This tag was read from a .pot file and is probably considered read-only/non-editable in weblate.

• If the tag is non-editable, I would still expect it to show up in a non-editable field below "tags" or it should have a read-only indicator in the side bar

So I observed the following, a little confusing behavior:

1. A string without "c-format" tag:
   ✔️ I can add and remove the "c-format" tag using the dialogue and the display is consistent with the sidebar
2. A string with "c-format" tag from .pot file:
   ❌ tag is not visible in the dialogue, but can still be "added"
   ✔️ tag is not added twice to the side bar when "save" is clicked
   ✔️ the "added" tag is still visible in the dialogue, when "edit" is clicked again
   ✔️ it can be removed again
   ✔️ removing the added "c-format" tag doesn't affect the original state, so I can't remove the tag when it was read from .pot. I think that is ok assuming that information from .pot is read-only in the UI.

The behaviour to me looks like the tag read from the .po file is read only, which is good in principle.
But: Should we be able to remove it for false c-format tags in the .pot file or should we say "fix your .pot file?"

So for the current behaviour the only enhancement that I'd like to see is that the non editable tags are indicated on the sidebar and/or shown in an non-editable field of the dialogue.

Screenshots

[nijel]

That's indeed confusing. The flags are collected at several levels:

• component configuration (https://docs.weblate.org/en/latest/admin/projects.html#translation-flags)
• translation (pretty much only read-only for non-editable source language)
• source string (this is what you can edit in the popup)
• extracted from the file
• translation string (currently used only on glossaries)

[luebbe]

Questions (we're getting into a discussion here ;-)):

• Are those flags limited in any way or are they totally free? I can't add a "smurf", "me-too" or other weird tag, so probably yes.
• If limited, wouldn't a kind of check-list be better than a free edit field?
• Can I filter by flags? Like "show me all c-format" strings?
• Are flags just a different kind of "label" and if yes, would it make sense to unify these two?

[nijel]

The flags were originally modelled based on GNU gettext ones and grown into [a huge list](https://docs.weblate.org/en/latest/admin/checks.html#customizing-behavior-using-flags.

As for the editing interface, please see #1567.

Flags and labels are different - flags configure Weblate behaviour (and thus it makes sense to provide component-level ones), while labels are user categorization only.

[luebbe]

#1567 is great info, thank you!

[nijel]

The interface will now explain this:

[luebbe]

Wow!
Maybe add an 🛈 with a link to https://docs.weblate.org/en/latest/admin/checks.html#customizing-behavior-using-flags behind "Inherited flags"?
Like: "Inherited flags 🛈" ?

One question remaining:

• Can I filter by flags? Like "show me all c-format" strings?

If this is not possible yet, I think it would make sense, since it would allow you to find strings with a certain behaviour.

[nijel]

Good idea, I've added it.

Searching by a flag is currently not possible. This would be currently problematic to search for a flag as these are stored in a text field in the database. So searching for "c-format" would yield "ignore-c-format" strings as well. The search also could be expensive because of merging flags from different sources...

[github-actions]

Thank you for your report; the issue you have reported has just been fixed.

• In case you see a problem with the fix, please comment on this issue.
• In case you see a similar problem, please open a separate issue.
• If you are happy with the outcome, don’t hesitate to support Weblate by making a donation.