Re: [libreoffice-l10n] Weblate's search results page lost in upgrade

-- Christian Lohmaier wrote on Jun 10, 2026 --
> On Wed, Jun 10, 2026 at 4:30 PM Tuomas Hietala <tuomas.hietala@iki.fi> wrote:
>
> >  However, if I search e.g. in UI master, I don't get the flat list of
> >  results, but have to click through every string instead:
> >  
> > https://translations.documentfoundation.org/translate/libo_ui-master/-/fi/?q=helpline&sort_by=component%2C-priority&checksum=
>
> Yes, that is the new behavior when going from the language view, you
> can also get back to the search listing by replacing the "translate"
> part of the URL with search:
> https://translations.documentfoundation.org/search/libo_ui-master/-/fi/?q=helpline&sort_by=component%2C-priority&checksum=

Manually changing "translate" to "search" works well for me, thanks for 
the tip.

> >  I'm not sure about that, but I think if I
> >  use the Search function in Weblate's UI, it would be much more useful to
> >  always get the flat list first.
>
> Apparently not everyone thinks that since the behavior was changed
> because of a issue that was filed upstream...
> https://github.com/WeblateOrg/weblate/issues/17057 /
> https://github.com/nijel/weblate/commit/347c52fe24e98057b1834994b27bdc71e252580d
>
> So I'd like to get more feedback before changing it back, at least you
> and Ming seem to prefer the search listing as initial result, but does
> anyone else prefer the way it is right now?
> Obviously currently it is hard to get to the searchlisting view since
> you have to manually modify the URL, but if there was a link e.g. next
> to the zen view icon that allowed you to go to the searchlisting -
> would people still prefer that the searchlisting would be the default
> page of a search?

I personally don't care too much which is the default -- I don't search that
frequently and even manually changing URL is good enough for me.  But if 
you want input, I think LibreOffice is somewhat unique in that it has a huge
amount (~50?) of components and that relevant strings usually span over 
several components (e.g. cui/, sw/ and svx/ for a single UI terminology change).
So when using the "translate" view, the translator needs to switch back and 
forth between components, which is (1) slow especially from big latency places
like China, and (2) easy to lose track of when there are many strings (from 
different UI changes) to translate. Therefore, in my workflow I usually just start 
with a "search" view and open related strings from different components in 
separate browser tabs.

Ming
-- 
To unsubscribe e-mail to: l10n+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/l10n/
Privacy Policy: https://www.documentfoundation.org/privacy