Moving translation files clears Weblate memory

[JulianGro]

Describe the issue

When moving translation files via git (with the move being reflected in it, not just a deletion and addition), Weblate will treat it as a new file and clear any translation data that isn't directly in the translation files.
Meaning if you had 5000 translation suggestions, well, you had them.

Asking Weblate care about it, this is seemingly “normal”. They added documentation describing the issue.

A comment on another issue suggests that this isn't supposed to happen: #7691 (comment)

I already tried

• I've read and searched the documentation.
• I've searched for similar issues in this repository.

Steps to reproduce the behavior

No response

Expected behavior

Suggestions:

• Weblate could lock the component if a translation file has been “deleted”.
• Weblate could keep the memory, inform you about it and link you to the relevant documentation page.

Screenshots

No response

Exception traceback

No response

How do you run Weblate?

weblate.org service

Weblate versions

Weblate 4.16.2-dev

Weblate deploy checks

No response

Additional context

[orangesunny]

Thanks for the feature request.

Here is the part of the documentation: https://docs.weblate.org/en/latest/faq.html#how-to-handle-renaming-translation-files

The behavior is normal and correct; no quotes needed. If the file that Weblate uses is no longer available in the remote repository, Weblate can’t find it on its own once the file is moved or renamed. Alert can be added, though.

[github-actions]

This issue has been put aside. It is currently unclear if it will ever be implemented as it seems to cover too narrow of a use case or doesn't seem to fit into Weblate.

Please try to clarify the use case or consider proposing something more generic to make it useful to more users.

[nijel]

When you move the files, the currently translated files disappear. Weblate in that case removes matching translations, including all additional data. There is a documented way to avoid that.

Dealing this better within Weblate is certainly possible, but this is quite an infrequent use case, and I currently see plenty of other improvements that would be useful for our users.

PS: In case we want to address this, #1993 might be the way to go.

[JulianGro]

I don't really see how not having Weblate delete your data is "an infrequent use case", but the way around these sort of issues seems to be to self-host Weblate so you get access to backups.

[orangesunny]

I don't really see how not having Weblate delete your data is "an infrequent use case", but the way around these sort of issues seems to be to self-host Weblate so you get access to backups.

Weblate deletes the data only if you instruct it to do it.

This use case is infrequent. It does not frequently happen that somebody changes the localization file structure/naming within the repository. Once you have it set up by the best practice, you carry it on. Movin repositories happen more often.

You always have full access to your data with Weblate. You can back them up, move them, or restore them; all your choice. https://docs.weblate.org/en/latest/admin/backup.html#project-level-backups

Let’s discuss the solution to prevent possible future inconvenience from this case.

[emmapeel2]

I am all for history on strings and having some record, but something in this ticket conflicts with how I think about suggestions: I wouldn't encourage more ways of piling up suggestions.

In fact, I have noticed that I need to push people a lot to review suggestions. Maybe the interface should be more pushy on suggestions, because having a suggestions laying around until the string changes and the suggestion is lost is... so... wasteful.

I like when there are no suggestions because they were all dealt with, is also a way to demostrate respect for the work to the people (and bots) that made the suggestion.