[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libreoffice-l10n] Weblate: Missing features, project folder view and search across the whole project
- Subject: Re: [libreoffice-l10n] Weblate: Missing features, project folder view and search across the whole project
- From: Cheng-Chia Tseng <firstname.lastname@example.org>
- Date: Tue, 17 Sep 2019 21:27:50 +0800
- To: Libreoffice Translation List <email@example.com>
Christian Lohmaier <firstname.lastname@example.org> 於 2019年9月17日 週二
> Hi *,
> On Thu, Sep 12, 2019 at 1:54 PM Cheng-Chia Tseng <email@example.com>
> > 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: firstname.lastname@example.org
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/l10n/
|[libreoffice-l10n] Weblate: Missing features, project folder view and search across the whole project||Cheng-Chia Tseng <email@example.com>|
|Re: [libreoffice-l10n] Weblate: Missing features, project folder view and search across the whole project||Christian Lohmaier <firstname.lastname@example.org>|
- Prev by Date: Re: [libreoffice-l10n] Weblate: Missing features, project folder view and search across the whole project
- Next by Date: [libreoffice-l10n] Weblate: admin rights and TMXs
- Previous by thread: Re: [libreoffice-l10n] Weblate: Missing features, project folder view and search across the whole project
- Next by thread: Re: [libreoffice-l10n] Weblate: Missing features, project folder view and search across the whole project