Merge failure on SecureDrop/SecureDrop at Weblate


It appears the string update has an error (maybe force pushing from the wrong base?). I received the following notification about weblate being unatble to merge the state of the latest branch.


 There has been a merge failure on SecureDrop/SecureDrop at Weblate.

Error message

Auto-merging securedrop/translations/zh_Hant/LC_MESSAGES/messages.po
Auto-merging securedrop/translations/ro/LC_MESSAGES/messages.po
CONFLICT (content): Merge conflict in securedrop/translations/ro/LC_MESSAGES/messages.po
Auto-merging securedrop/translations/pt_BR/LC_MESSAGES/messages.po
Auto-merging securedrop/translations/it_IT/LC_MESSAGES/messages.po
Auto-merging securedrop/translations/is/LC_MESSAGES/messages.po
Auto-merging securedrop/translations/es_ES/LC_MESSAGES/messages.po
Auto-merging securedrop/translations/el/LC_MESSAGES/messages.po
Automatic merge failed; fix conflicts and then commit the result. (1)

Repository status

On branch weblate-merge-tmp
Your branch is up to date with 'origin/i18n'.

You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Changes to be committed:

	modified:   securedrop/translations/el/LC_MESSAGES/messages.po
	modified:   securedrop/translations/es_ES/LC_MESSAGES/messages.po
	modified:   securedrop/translations/is/LC_MESSAGES/messages.po
	modified:   securedrop/translations/it_IT/LC_MESSAGES/messages.po
	modified:   securedrop/translations/pt_BR/LC_MESSAGES/messages.po
	modified:   securedrop/translations/zh_Hant/LC_MESSAGES/messages.po

Unmerged paths:
  (use "git add <file>..." to mark resolution)

	both modified:   securedrop/translations/ro/LC_MESSAGES/messages.po

Thank you @dachary for the update.

Do you know how / if this will affect contributions to translations and review? I hesitate to make a string freeze announcement and encourage contributions if they will be interrupted or affected somehow.

1 Like

It would be wise to wait until the issue is resolved. Adding translations to a repository that is diverging from the source could involve frustrating manual re-assembly after the problem is fixed. I’m however confident this can be resolved quickly: it’s probably a simple mistake :slight_smile:

1 Like

Thank you @dachary!

I also pinged @kushaldas in Mattermost for more info. I’ll hold off on announcements until I hear more back.

1 Like

i don’t know what caused the conflict, it happened after I pushed the changes from the develop to the i18n branch, it said unknown commits which were not there in git branch I had used. I cleaned it up before unlocking the repository for translation.

@kushaldas the actual list of git commands you used (git push --force? git rebase?) to get to the current state would be most helpful. And also the git reflog in case some commits of interest are now orphaned.

When you write it said unknown commits which were not there in git branch I had used could you explain what it means exactly? It does not ring a bell. And when you write I cleaned it up, the actual command you used are probably the reason for the current conflict and it would be super helpful to have them.

I’ll take a look at the state of (and read to refresh my memory) to see if I can figure out the problem.

It looks like the thing to do here is to manually resolve any conflicts: but first understanding how this arose would be useful

1 Like

@redshiftzero it would be helpful for me to have admin access to to analyze the problem.

From I see was the last modification from two days ago and it is in so … there is no divergence.

The good news is … the repository is no longer in conflict :tada: I assume @kushaldas clicked on Reset in the commit page, discarding local changes that triggered the conflict.

We won’t know which changes were lost in the process. In any case this would have only impacted the romanian translation and (as stated above) all changes are accounted for. Whatever modification triggered the conflict must have been metadata and not actual translation. All other files were merged.

Next time around @kushaldas I would be happy to discuss any unexpected behavior you face and try to understand and resolve them together. The best non destructive option would be by resolving the conflicts locally as suggested by @redshiftzero.

IMHO @erinm it is now safe to announce the string freeze to translators, assuming @kushaldas or @redshiftzero concur with my assessment. And @jobaval10n could double check nothing is missing from his (awesome) work :wink:

1 Like

To test I’ve done the following:

  1. Made a small change via the Weblate UI which is committed to the local repository:
  2. Clicked Push manually (i.e. not waiting for automatic push, which is configured), verified the change is pushed successfully to the remote.
  3. Clicked Pull to update the local repository from the remote, all is well.
  4. Verified the strings we added last night (related to Noscript) now appear in the Weblate UI.

So I agree with @dachary (:heart:) that translators can go ahead and begin translating.

The alert (which appears in the UI as a triangle with an exclamation point inside -> :warning: ) is not automatically dismissed, investigating how to resolve that now…

1 Like

It is somewhere in Log in | Weblate administration IIRC

1 Like

I looked into this, and the alerts unfortunately were not dismissible via the Admin UI. Looking at the docs, it says that they “cannot be ignored, but will disappear when the underlying problem has been resolved” (ref).

Next looking at the Weblate code here, there is a task that runs once a day that updates (adds/deletes) component or repository alerts. Now that the underlying issue is resolved, I’ll wait a day and my expectation is that the alert will be naturally deleted now that there are no conflicts. To be continued…

I saw the same, and then only decided to reset the local repository. Before next time, I will make sure to have access to the server, so that I can login and verify things there.

Thanks everyone for looking into this and resolving so quickly!