Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Improve auto locking #245

Closed
xmorave2 opened this issue Apr 9, 2013 · 6 comments
Closed

Improve auto locking #245

xmorave2 opened this issue Apr 9, 2013 · 6 comments
Assignees
@nijel
Labels
enhancement Adding or requesting a new feature.
Milestone
2.18

Comments

@xmorave2
Copy link

xmorave2 commented Apr 9, 2013 •
edited by nijel
Loading

It would be great (if it is possible) to have auto locking function working more sophisticated.

My idea is, to lock only each one string, which is currently translated.

It means, that when somebody opens the string for translation, this string is being locked and, if somebody else is going to translate, this locked string is automatically skipped.

If somebody tries to open currently locked string, the message will display and "Save" button will be inactive, as it is now for whole sub-project.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
@nijel
Copy link
Member

nijel commented Apr 23, 2013

In most cases it is better to translate messages that follow at once as
they are usually related, so locking single message would not help in
this situation much. Actually locking (configurable) chunk of messages
might be better approach than current locking of whole translations.

Also see issue #175 for previous discussion on this topic.

@xmorave2
Copy link
Author

It sounds much better than my previously described idea. I think it would be nice enhancement.

@Changaco Changaco mentioned this issue Jan 23, 2016
Open
@nijel nijel mentioned this issue Jan 27, 2016
Closed
@marcperrin
Copy link
Contributor

Hi nijel,

Before thinking about a more ambitious chunk-based lock, do you think there is value in making a simple feature that lets (based on settings) the auto lock work at unit level instead of translation level? Or do you think we would be better off just deactivating the auto lock?

(got some user feedback about not being able to collaborate on a single translation)

Thanks,

Marc

@nijel
Copy link
Member

nijel commented Jun 29, 2017

The chunk based locking would in the end be implemented on unit level anyway, so it's pretty much same approach.

nijel added a commit that referenced this issue Dec 5, 2017
@nijel
Use select_for_update() when updating units
83cf8c3 
This should avoid potential race conditions when auto locking is
disabled.

Issue #245

Signed-off-by: Michal Čihař <[email protected]>
nijel added a commit that referenced this issue Dec 5, 2017
@nijel
Verify that unit has not been changed before translating it
0c69ecd 
This way we can remove locking as ovewriting now has to be confirmed.

Issue #245

Signed-off-by: Michal Čihař <[email protected]>
@nijel nijel self-assigned this Dec 5, 2017
@nijel nijel added this to the 2.18 milestone Dec 5, 2017
@nijel nijel closed this as completed in 64e5016 Dec 5, 2017
@nijel
Copy link
Member

nijel commented Dec 5, 2017

Thank you for your report, the issue you have reported has just been fixed.

  • In case you see problem with the fix, please comment on this issue.
  • In case you see similar problem, please open separate issue.
  • If you are happy with the outcome, consider supporting Weblate by donating.

@marcperrin
Copy link
Contributor

marcperrin commented Dec 5, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nijel nijel

Labels
enhancement Adding or requesting a new feature.
Projects
None yet
Milestone
2.18
Development

No branches or pull requests
3 participants
@nijel @xmorave2 @marcperrin