I have the same problem as @kmikkels, the hundreds of phrases in form_ca.xml and form_us.xml (see Weblate translation form xml file ). They are totally useless in Finland, too.
Is there a filter or other way to skip certain modules or source files? My solution has been to start the translations in reverse order, from the end to the beginning, but I am afraid these are not only files to skip.
There’s a “component” organization feature and a string granular prioritizing feature in the Weblate ecosystem. And there’s a filtering option in the Weblate interface too.
I suppose that some labels in english are “totally useless in Finnish or French, Spanish, etc.” for translators (to translate; extra work). Maybe keep it untranslated to have labels (and attributes) into the original locale (eg, census in UK or USA). On the other hand, to translate them for locales using Arabic, Chinese, Hebrew, Japonese, etc. might be still useful…
A hundred untranslated label means that every time I start working I must pass every one of those by clicking mouse. But I’ll check the options @emyoulation mentioned.
I have a bulk edit in progress which should set a priority of 50 to all strings in the Form definition files. The default priority is 100 and strings can be presented for translation in priority order.
If this is successful then we can think about raising the priority of important strings in the Program component. This should be useful for the translators of newly added languages.
How about adding 5 to all plugin strings? (both built-in and for the addon project) That would make core code strings higher than plugins.
We can think about how we want to structure string priority. What strings are fundamental? What strings are in the main window and essential dialogs?
The bulk edit is a very blunt tool. Trying to use it to add a priority flag to all plugins probably won’t work well.
Let’s see if the approach is useful in the Addons component first. The bulk update is complete now and a priority flag was added to 1975 strings.
The solution that works for me is a filter “state:<translated and not (location:form_ca or location:form_us)” [edited]. I’ll bookmark this in my browser.
This isn’t a criticism of the following features but just an observation…
There are feature that have HUGE sets of configuration options. And the label strings are not even marginally harmonized between them.
Some reports (like the Narrated Web site) and views (like FTV and CardView) have a multitude of tabs. Each adds dozens of strings to be translated. And (generally) labels in options/preferences are terse and are never re-written from their original rough drafts.
So perhaps our LLM experts could suggest ways the glossaries could be analyzed and refined to consolidate option labels?