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.

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

Duplicate jobs when converting to alias and back #22

Open
zerolab opened this issue Aug 13, 2024 · 1 comment
Open

Duplicate jobs when converting to alias and back #22

zerolab opened this issue Aug 13, 2024 · 1 comment

Comments

@zerolab
Copy link
Collaborator

zerolab commented Aug 13, 2024

Working down the TODO list

  1. start off with a translation (with mark for Smartling). We have a Job object
  2. convert the translation to alias. This removes the translation object, leaving the Job object without a reference to translations
  3. translate (with mark for Smartling). This creates a new translation object, as well as a new Job object

When we translate and mark for Smartling we could check existing jobs for the matching translation source that don't have any translations

  • if unsynced
    a) update the m2m with the new translation?
    b) delete the job and recreate?
  • if synced and in progress in Smartling
    a) cancel the job in Smartling?
    b) update the Job m2m with the new translation?

This works best for a Job with one target locale. If there are multiple this gets more complicated in that we need to check how many have recreated etc

--

The alternative - look at disabling "convert to alias" if the translation has a Job that is either unsynced or in progress in Smartling. And I leaning towards this

@stevejalim
Copy link
Collaborator

I think it's more likely that pages will have more than one target locale (typically ~8 at a guess), so we'd certainly be in the "more complicated" zone here.

FWIW with mozilla/bedrock, one thing we've got built in is middleware that falls back to the next-best-fit locale if any page (from Wagtail or just Django) isn't available in the requested locale -- this behaviour should mean that we won't need to use alias pages in reality.

As such, I think the alternative approach - simply don't allow this situation to come to pass - is probably the wise one right now.

(We could keep this ticket around as a closed Issue as a reminder of an approach to cope with things if we did need to allow aliases to exist.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants