Why do yo need it?
The reasoning for the current behaviour is that the user wants to either focus on standard components only (to minimise their workload), or search in all components. That's why we have two "All" and "Standard only" links.
What is the use case for wanting to filter non-standard components only?
Hi David,
I will detail what i wrote in my first message, based on a recent exemple i've just had.
I wanted to review all strings containing 'URL' in french language. I've first done the work on standard components, because it would have been to much strings with 'everything' selected, and it's more important to work on standard components.
When i still have some time to continue the work on it (i could yesterday), i don't want to see anymore components i've already worked on (generating lot of results). But i don't have easy solution to see only what i've not already done (non standard components).
I should 'select all' and then click on all standard components (to deselect them), or click on all non standard components. Tooooo much in each case
How could i achieve that?
I think i'm not the first or only one to first work on standard components, and then on non standard. Of course, when you only want to translate/review translation on just some components, it's not a problem. But when you have to work on everything, it could be useful to be able to first work on standard, and then on non standard (because you don't have time to do everything at the same time).
Séverin
> i don't want to see anymore components i've already worked on (generating lot of results)
I see your point. However. Let us say we have this feature and so you are able to select all non-standard components. So you can easily select all 1349 components. Say 10% of them contains "URL" is some string, so you still end up with roughly 100+ selected components / strings. How will this new feature help you to not "see anymore components i've already worked on" ?
I admit this is kind of devil's advocate question, please don't get me wrong I just want to make sure that the feature requests are backed up with solid and thought-through use cases before we report them.
Hi David,
I completly understand that you only want to work for really useful things, and not implement everything everybody thinks about.
To be exact, with my actual problem (strings containing URL, in uppercase) : i've already reviewed 335 strings in french for standard components. If i select all components, i end with 723 strings. So, i've already done nearly half of the work. But, knowing that 171 strings aren't translated, i only have 723 - 335 - 171 = 217 strings to review (less than 40% of the work).
It's not too much work if i can find them easily ; if they're mixed with already reviewed one, it's much more work...
To write things short : it would ease the fact of working first on standard (priority), and then on non standard easily (when you've more time).
Séverin
PS : perhaps my use case is unusual ; i'm used to do things that are unusual to most people
