Component-level locking prevents concurrent autotranslation for multiple languages - Is this intended behavior?

[dxdx123]

Summary

I'm experiencing component-level locking that prevents multiple languages from running autotranslation simultaneously within the same component. I'd like to confirm if this is the intended behavior and understand the technical rationale behind it.

Current Behavior

When running autotranslation (using machine translation services like Azure OpenAI or AWS Claude) on a large component (~56,000 strings), I observe:

1. ✅ First language (e.g., Italian) starts autotranslation successfully
2. ❌ Attempting to start autotranslation for other languages (Chinese, French, etc.) fails with:

   WeblateLockTimeoutError('Lock on [component-name] (component-update) could not be acquired in 5s')
   

3. ✅ After the first language completes, other languages can be translated

Environment Details

• Weblate Version: 5.10
• Deployment: Docker on Alibaba Cloud Linux
• Component Scale: 56,161 strings across 5+ languages
• Machine Translation: Azure OpenAI, AWS Claude

Technical Investigation

Through Django shell investigation, I confirmed:

• All languages in the same component share the same lock key (e.g., lock:component-update-lock-295)
• Queue status shows no task backlog (celery_queues returns 0 for all queues)
• The lock mechanism appears to be at the component level, not language level

Questions for Maintainers

1. Is this the intended behavior? Should autotranslation be serialized per component?

2. What's the technical rationale? Is this due to:

   • Git repository integrity concerns?
   • Database consistency requirements?
   • Resource management considerations?

3. Is this related to Issue Support translation to multiple languages in parallel #197? While that issue discusses manual multi-language editing, this concerns automated translation concurrency.

4. Are there any plans to support concurrent autotranslation? For large components, serialized translation significantly increases processing time.

Use Case

We have several large components where:

• Multiple translators work on different languages
• Autotranslation helps bootstrap translations before human review
• Current serialization means a 5-language component takes 5x longer to auto-translate

Potential Solutions (if this is a limitation)

1. Component-level configuration to allow concurrent autotranslation when safe
2. Language-level locking instead of component-level for autotranslation
3. Queue-based autotranslation with better resource management

Request

Could the maintainers confirm:

• Whether this behavior is by design
• The technical constraints that require it
• Any potential roadmap for concurrent autotranslation support

Thank you for maintaining this excellent translation platform!

[nijel]

The locking is currently needed because automatic translation is likely to trigger commit, and that one needs locking. So better to acquire lock before the operation than fail on it during it in a deadlock. Once #8770 is implemented, this will no longer be an issue and the component lock can probably be avoided in this situation as described in #13623.