Date: prev next · Thread: first prev next last
2019 Archives by date, by thread · List index

Christian Lohmaier <> 於 2019年9月17日 週二

Hi *,

On Thu, Sep 12, 2019 at 1:54 PM Cheng-Chia Tseng <>

In Pootle, translators can search specific term/translation in the whole
project, such as LibreOffice UI, LibreOffice Help, LibreOffice Online,

You can also search in a whole project in weblate.
But what weblate doesn't offer is limiting search to a "folder" (since
weblate doesn't have concept of folders)
So in weblate it is either whole project or single file (component)

If I am working on LibreOffice UI/ LibreOffice Online, then I donʼt want to
go through LibreOffice Help when searching.
Fixing translations in LibreOffice Help is kind of time-consuming and
torturing, so I work with UI/Online first. :S

This feature enables translators to check existing terms or translations
and fix them.

Hmm. I wonder whether an additional Glossary-based check would fill
this gap in a more elegant way?
I.e. you add your terms to glossary/terminology and we maybe could
write a check for strings that don't have a translation that matches
the glossary.

Weblate already has a default "inconsistent translation" check
that follows a similar idea (but is not enabled in our instance
currently, since same string is corner case in our project, and more
likely than not it is in different context that requires different
translation, so I'm afraid that check would cause too many false
positives) - and for same string weblate has dedicated "other
occurrences" section when doing regular translation, example:

Yeah, I do notice the feature as I work on Weblate to translate the UI of
Weblate for some years.
However, finding inconsistent translations is another issue.

The idea of searching across the whole project mentioned above is mostly
happened when we are "changing the translation of specific terms".

Listing the components as folders under the project and searching text
across the whole project are quite important features in the daily
translation workflow.

But this also sounds also like something that can be done more easily
offline, with the po files directly?

Thatʼs true we can do it offline, but the challenge we face is that Pootle
does this well online and we are used to it. T-T

That said: if we were to have a solution for aggregation by folder, we
could put both help and ui into a single project solving your issue?
Not sure whether I did really understand the problem correctly.

Yes! That might be a good solution. :)

The way Pootle works is designed to serve multiple translation files
different projects which fits LibreOffice well while Weblate is not.

Don't quite get that, since pootle also is limiting stuff on a
per-project basis. (but within the project it works on folders, with
automatic aggregation, that's right)

Agree. It is more about the user experience part for translators working on
multiple files under one project, although it might seem nothing special.

If we are moving to Weblate, and that should be solved to fill the
gap between them.

Can you give a full example of what you do in pootle currently?
That would help me understand the issue better and maybe come up with
an easier workaround.
(Since adding folder-based view on weblate is nothing you should wait
for - that would likely take a while/if at all...)

I typically click "LibreOffice Master UI" first, then click the different
components to translate.
If I find something translated wrongly (I may notice it in fuzzy, under the
translation memory pane below or see it in neighboring strings) when I am
going though the fuzzy/untranlsated strings, I will do the cross search
between projects (such as Master, LibreOffice 6.3 UI, LibreOffice 6.2 UI)
to fix them all at once (like bug fix and backport).

Actually, I totally support the move to Weblate in any time.

I just want to express that Poole has some advantages that we are used to,
and it is always better that we can have that again no matter how much the
time it might take.
There will be more of joy when we translate for LibreOffice projects as
before with folder-based view.
I also work on other small projects which have few files as well. I don't
think folder-based view is needed with those small projects.
However, in my point of view, LibreOffice needs it because of the
complexity of files.

If we canʼt have that after all, it is fine as well because we have
collected opinions and tried methods together with Weblate developers to
bring them back and failed.

by Cheng-Chia Tseng

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.