Better interface for editing flags

[burner1024]

related: #1560 Having to specify flags as a comma separated list is somewhat unintuitive, and prone to errors. Maybe it's better to display them as actual flags - checkboxes? Also, that way more detailed descriptions could be displayed next to them, or as a tooltip.

[nijel]

Well there is interface to add new flags:

But it's not really easy to use as there are too many flags...

The original intention was to turn it into full featured editor at some point, but it was never implemented.

[burner1024]

Looking for this UI, but I cannot find it my Weblate 2.15. How do I even get to this page?

[nijel]

It's when editing per string flags, see https://docs.weblate.org/en/latest/admin/checks.html#custom-checks

[nijel]

The list of flags got really huge over the time, so we really should do something about this:

[nijel]

My idea how to deal with this:

• Tag style editor (see example)
• Autocompletion
• Editing of parameters for parametrized checks
• Validating of parameters for parametrized checks
• Ensuring each tag is included only once

[burner1024]

I don't know about per unit checks, but at least on component level I think it'd make more sense to list them as a list of checkboxes still. Using autocompletion requires knowing what checks are possible in the first place.

[nijel]

I think there is way too many of them for checkboxes and the list will grow. Also some of them accept parameters, what would make the form even bigger.

[burner1024]

Maybe, but in my opinion using tags for flags is bad design, because generally tags is something that users make up themselves, rather than selecting from a pre-defined set, which is what checkboxes are used for, usually. (To help with overly long lists, checks can be grouped, with groups separated visually).

But I don't use this feature that often, so I'll leave it to your better judgement.

[nijel]

Hopefully it will not be myself implementing this in the end, so the final decision will be on somebody with better UI skills than me.

[nijel]

As we now have CodeMirror in our codebase, it might be an option for this. It can have syntax highlighting and code completion for the flags syntax. Right now it is plain textarea with no additional controls.

[JohnRDOrazio]

When dealing with a single translation string, that has a check flag such as inconsistent, mismatched full stop, mismatched ellipsis, untranslated and any other quality checks, it would be useful to have the appropriate flag suggested when trying to apply a flag that will silence the quality check. If for example the phrase is untranslated and gets flagged as such by quality check, it would be useful when clicking on "add flag" to have the ignore-same flag suggested. (Currently I am continuously opening the documentation page to look up the name of the flag that I need each time to silence the quality check).

I saw that in the latest updates, there is a button to ignore the quality check, however this button does not add an appropriate flag, and the quality check winds us popping up again as soon as the source strings have some change to them. At least this seems to be the experience I have been having.

[JohnRDOrazio]

For example, clicking here on Dismiss seems to only actually dismiss the quality check temporarily. I will soon have the quality check pop up again (I'm guessing if the source strings have had any changes; for gettext strings this could even happen when the translation strings are the same but refer to different lines in the source code, so the pot file has changed...)

It would be nice, when clicking on edit flags, that an ignore-end-ellipsis flag were automatically suggested, or were applied when clicking on the Dismiss button nearby the quality check.

[nijel]

Dismissing for all languages adds corresponding flag to the source string...

[JohnRDOrazio]

Ok yes I can confirm this, you don't see the flag added right away, but after navigating away and navigating back again, the flag is set. Thank you! I wonder if we could implement some javascript magic to show the updated flag field right away when dismissing for all languages.

I believe this code is responsible for the dismiss action:

https://github.com/WeblateOrg/weblate/blob/eec50fb50357029fd8fa6f4a6cfe5b7a6602e71c/weblate/static/editor/full.js#L318-L327

Perhaps adding a success callback that updates the flags field?

[nijel]

@JohnRDOrazio is working on this at https://github.com/WeblateOrg/weblate/pull/7291

[JohnRDOrazio]

Looking for this UI, but I cannot find it my Weblate 2.15. How do I even get to this page?

I haven't actually succeeded in finding this view either. If I open a component, and open the source strings, I have two buttons Browse and Translate.

Browse will show me a simple list of the source strings. Clicking on any of the strings will take me to the translate interface.

Translate will open the translate interface, where the source strings can be either read-only or editable if they were set as editable in the component settings.

I'm not sure where the source-strings -> review interface is to be found.

In any case, which view would that be in the source code? I would like to take a look at how the long list of possible flags is being generated.

[JohnRDOrazio]

I've been working on giving visual feedback of flags added by the "Dismiss for all languages" button. I suppose I could also work at the same time on an interface for adding flags, for example I think we can organize the flags into categories. Something like this:

Treat text as	Enable check	Ignore check	Render check	ICU behavior	String behavior
rst-text	check-glossary	ignore-bbcode	font-family:NAME	icu-flags:FLAGS	dos-eol
xml-text	angularjs-format	ignore-duplicate	font-weight:WEIGHT	icu-tag-prefix:PREFIX	read-only
md-text	c-format	ignore-check-glossary	font-size:SIZE		priority:N
	c-sharp-format	ignore-double-space	font-spacing:SPACING		max-length:N
	es-format	ignore-angularjs-format			placeholders:NAME:NAME2:...
	i18next-interpolation	ignore-c-format			replacements:FROM:TO:FROM2:TO2...
	icu-message-format	ignore-c-sharp-format			variants:SOURCE
	java-format	ignore-es-format			regex:REGEX
	java-messageformat	ignore-i18next-interpolation			forbidden
	javascript-format	ignore-icu-message-format			strict-same
	lua-format	ignore-java-format			url
	object-pascal-format	ignore-java-messageformat
	percent-placeholders	ignore-javascript-format
	perl-format	ignore-lua-format
	php-format	ignore-object-pascal-format
	python-brace-format	ignore-percent-placeholders
	python-format	ignore-perl-format
	qt-format	ignore-php-format
	qt-plural-format	ignore-python-brace-format
	ruby-format	ignore-python-format
	scheme-format	ignore-qt-format
	vue-format	ignore-qt-plural-format
	safe-html	ignore-ruby-format
		ignore-scheme-format
		ignore-vue-format
		ignore-translated
		ignore-inconsistent
		ignore-kashida
		ignore-md-link
		ignore-md-reflink
		ignore-md-syntax
		ignore-max-length
		ignore-max-size
		ignore-escaped-newline
		ignore-end-colon
		ignore-end-ellipsis
		ignore-end-exclamation
		ignore-end-stop
		ignore-end-question
		ignore-end-semicolon
		ignore-newline-count
		ignore-plurals
		ignore-placeholders
		ignore-punctuation-spacing
		ignore-regex
		ignore-same-plurals
		ignore-begin-newline
		ignore-begin-space
		ignore-end-newline
		ignore-end-space
		ignore-same
		ignore-safe-html
		ignore-url
		ignore-xml-tags
		ignore-xml-invalid
		ignore-zero-width-space
		ignore-ellipsis
		ignore-icu-message-format-syntax
		ignore-long-untranslated
		ignore-multiple-failures
		ignore-unnamed-format
		ignore-optional-plural

The ignore-check category can probably be subdivided better. Anyone have any suggestions on how to best categorize all these flags?

[burner1024]

Grouping looks good to me. The original request was about the component flag editing in admin area, though, not individual string ones.

But I'm not sure if it's the same in current Weblate release, been stuck on 3.x for a while.

[JohnRDOrazio]

Here's a new table that lines up the ignore-checks with other related flags. The "String behavior" column is kind of its own thing here... There's probably even better ways to group and categorize these flags, I'm not yet familiar enough with all of them.

Ignore check	Treat text as	Enable check	Render check	ICU behavior	String behavior
ignore-check-glossary		check-glossary			dos-eol
ignore-angularjs-format		angularjs-format			read-only
ignore-c-format		c-format			forbidden
ignore-c-sharp-format		c-sharp-format			priority:N
ignore-es-format		es-format
ignore-i18next-interpolation		i18next-interpolation			replacements:FROM:TO:FROM2:TO2...
ignore-icu-message-format		icu-message-format			variants:SOURCE
ignore-java-format		java-format
ignore-java-messageformat		java-messageformat
ignore-javascript-format		javascript-format
ignore-lua-format		lua-format
ignore-object-pascal-format		object-pascal-format
ignore-percent-placeholders		percent-placeholders
ignore-perl-format		perl-format
ignore-php-format		php-format
ignore-python-brace-format		python-brace-format
ignore-python-format		python-format
ignore-qt-format		qt-format
ignore-qt-plural-format		qt-plural-format
ignore-ruby-format		ruby-format
ignore-scheme-format		scheme-format
ignore-vue-format		vue-format
ignore-safe-html		safe-html
ignore-url		url
ignore-same	rst-text	strict-same
ignore-max-length		max-length:N
ignore-max-size		max-size	font-family:NAME
			font-weight:WEIGHT
			font-size:SIZE
			font-spacing:SPACING
ignore-regex		regex:REGEX
ignore-placeholders		placeholders:NAME:NAME2:...
ignore-xml-tags	xml-text
ignore-xml-invalid
ignore-md-link	md-text
ignore-md-reflink
ignore-md-syntax
ignore-end-colon
ignore-end-ellipsis
ignore-end-exclamation
ignore-end-newline
ignore-end-space
ignore-end-stop
ignore-end-question
ignore-end-semicolon
ignore-begin-newline
ignore-begin-space
ignore-escaped-newline
ignore-newline-count
ignore-double-space
ignore-zero-width-space
ignore-ellipsis
ignore-punctuation-spacing
ignore-plurals
ignore-optional-plural
ignore-same-plurals
ignore-translated
ignore-long-untranslated
ignore-duplicate
ignore-inconsistent
ignore-multiple-failures
ignore-bbcode
ignore-icu-message-format-syntax				icu-flags:FLAGS
				icu-tag-prefix:PREFIX
ignore-kashida

And I wonder if certain flags are mutually exclusive? Like wouldn't the Enable check and Ignore check columns be mutually exclusive? Should the interface prevent you from adding an Enable check flag if the corresponding Ignore check flag is already added? And vice-versa?

[burner1024]

from UI pov, I'd say they shouldn't prevent, but cancel each other (although there should be still a way to remove both flags)

[buhtz]

IMHO the problem with this Issue is that it is to "meta". It describe multiple problems and approaches. The problems and working packages should be atomized and described in separate issues.

[nijel]

There is a single problem in this issue: Provide a better interface for editing flags

The approach is yet to be chosen, and then it might make sense to create separate issues to implement it…

[buhtz]

There is a single problem in this issue: Provide a better interface for editing flags

That is a wish or goal not a "problem". You really should do more analysis of Weblates UI "problems". I try to provide this with providing Issues, Screenshots and description of concrete use cases. But you just closed.

IMHO your approach to handle such problems is part of the problem. You are to deep into the code, the backend and internals of Weblate. You need to step back to get a bigger picture from outside and try to be more emphatic to your users. I try really hard to be empathic to the maintainers and devs of this probject with providing user-related Issues that can be understand by devs, too. Let's meet in the middle. ❤️

[nijel]

That is a wish or goal not a "problem".

Okay, it's a goal, not a problem. This issue is here to find a way to make editing of the flags more user-friendly. People discussed possible approaches, what might sound meta, but that's a way to find a solution.

You really should do more analysis of Weblates UI "problems". I try to provide this with providing Issues, Screenshots and description of concrete use cases. But you just closed.

If you are talking about https://github.com/WeblateOrg/weblate/issues/10391, yes I just closed that because this issue covers the same topic. I've also explained why checkboxes are not a viable solution, as they don't cover part of the flags.

IMHO your approach to handle such problems is part of the problem. You are to deep into the code, the backend and internals of Weblate. You need to step back to get a bigger picture from outside and try to be more emphatic to your users.

My input in this was what all flags the UI needs to handle. Yes, that's coming from Weblate internals, but that's necessary information for this feature.

Anyway, we're getting really off-topic here. https://github.com/WeblateOrg/weblate/discussions/ is the place for generic discussions.

[JohnRDOrazio]

Grouping looks good to me. The original request was about the component flag editing in admin area, though, not individual string ones.

But I'm not sure if it's the same in current Weblate release, been stuck on 3.x for a while.

I'm not familiar enough with usage of flags, but can all flags be applied equally to single strings and to components? Or are some flags for components and some for strings? I've never used flags on the component level.

[nijel]

Any flag can be applied for both levels, resulting flags are merged from all sources (see https://docs.weblate.org/en/latest/admin/checks.html#customizing-behavior-using-flags). Some of them (for example max-length:N) don't make much sense at the component level, but still, they can be provided as a default value which is then overridden for some strings.

[JohnRDOrazio]

May I ask for feedback on the following UI: https://codepen.io/johnrdorazio/pen/bGzvZEE?editors=1000

This is not at all a final HTML structure, I haven't set up all the ids and values and such. This is just to have a general idea of how the interface could be set up, so as to move from comma separated strings that you have to guess at, to a UI that allows to set the behaviour of translation checks without even having to know about flags. Flags should be more of a "pro" option, but most users shouldn't even have to ever know they exist, if there is an intuitive UI to help tune the behaviour of translation checks.

One thing that I believe needs to be taken into account is context: in my understanding, not all flags are useful in all contexts. Some are useful in the glossary, some are useful in the component settings, some are useful for a single translation string. I have no idea which ones are useful where, so I could use some help on clarifying the context.

[nijel]

I think this is a great starting point!

As for the context: currently, no checks are performed on a glossary, so there only read-only, forbidden and terminology flags make sense. In translations, only the terminology and forbidden flags are not used.

The flags categories and logic should be based on weblate/checks/flags.py and not hard-coded to gracefully handle flags from new checks. Most likely it will need some restructuring because it was not really built with UI in mind (for example, TYPED_FLAGS_ARGS defines parsing of the arguments, but does not actually describe their structure).