Add concept of deprecated translation keys

[vmassol]

It would be nice to be able to mark keys as being deprecated.

For example on the XWiki open source project, we keep old deprecated keys in a special section in our Java properties file since we don't want to break extensions using those keys. OTOH on weblate we'd like them to be filterable/hidden by default or at least tagged as "deprecated" so that users know that they shouldn't focus on them and that they're not the important ones.

Possible? :)

Thx

[nijel]

In translate-toolkit this state is called obsolete. It's currently supported only for Getext PO files and Qt TS. Still I'm not sure how much useful would be to load such entries into Weblate - there is certainly no use for editing those.

[vmassol]

there is certainly no use for editing those.

A deprecated key means we don't use this key anymore in new versions of the XWiki software but it can very well be used in XWiki extensions (we have over 700) and this key may be missing translations in a given language that some contributors may want to contribute too.

I agree the need is not huge but I think it's there. Now in our case the deprecated keys are in the same properties file so there's no way for us to filter this out so I guess we would need to refactor XWiki to use different properties file which is a bit painful/complex, or write some python scripts to filter those keys out when importing into Weblate.

[nijel]

This could be also useful for removing strings first in Weblate database and doing that in the translation file later when doing commit.

[comradekingu]

My use for this is to hide strings from being shown as untranslated in the Weblate UI.

[festugreat]

Hello, Kindly stop sending me this emails,effect from now. Thanks.

…

On Thu, 18 Mar 2021, 11:22 pm Allan Nordhøy, ***@***.***> wrote: My use for this is to hide strings from being shown as untranslated in the Weblate UI. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1993 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJJ6RX73K6YROYGE7YGQTCLTEJ4IRANCNFSM4E564W6Q> .

[nijel]

@festugreat Kindly stop spamming this issue tracker, effect from now. If you want to unsubscribe, you use the link in the e-mail you've replied to.

[burner1024]

@nijel any idea in which version/milestone this might become available? I don't mean any pressure, of course, just would like to plan accordingly too, if possible. (We're on version 3.1 and can't really upgrade until string deletion works faster.)

[nijel]

Currently, this is not on the roadmap.

[burner1024]

Got it. Sent some change via github.

[ALIENQuake]

@nijel Is there bountysource for this issue? Or something that could make this into consideration?

[nijel]

Bountysource is probably no longer working (at least getting money out of there is not working). I don't know if there is some alternative for funding individual issues.

[burner1024]

Maybe just use a special label for this?
This is biting us again... Github finally disabled their deprecated oauth scheme, so now we can't use Github auth until upgrade :(.
I'm looking for a way to allow users to mark the strings and delete them later through cron or something, but such metadata is not saved in PO, and deleting through API will be slow too, blocking the component in process.
Any workaround suggestions?

[nijel]

Reading this again, there are more topics discussed in this issue:

• flagging some strings in Weblate to avoid their translation, but keep existing translations, this has no representation in the file
• parsing obsolete strings from some formats (for example Gettext), such string would be useful for translation memory
• optimizing string removal, what would use the obsolete string temporarily until these are removed from the file

Unfortunately, I don't see any good workaround for the third case.

[burner1024]

parsing obsolete strings from some formats (for example Gettext), such string would be useful for translation memory
optimizing string removal, what would use the obsolete string temporarily until these are removed from the file

Maybe for beginning just mark the strings in the database for removal, and worry about moving them to obsolete state/translation memory later?
I'm grasping at straws here... Looked through API, it seems there's no bulk removal, so whatever I do is going to be slow as hell.

[nijel]

Revisiting this issue a few years later, there are following issues handle two specific topics discussed here:

• Delayed removal of strings #10787
• Add component filtering based on key #11562

What is left open and of this issue are the actual deprecated strings.