Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#1626 closed feature request (fixed)

Add automated/transparent MultiLang workflow support with multiple fallback languages

Reported by: jval Owned by: jval
Priority: major Milestone: 8.09.8 Ragnaroek
Component: MidCOM core Version: 8.09 Ragnaroek
Keywords: Cc:

Description

The MultiLang feature in Ragnaroek has only one fallback language and the default workflow has the concept of one certain master language (content is always created in the same specific language and translated in others).

I needed a different kind of MultiLang where I can create content in any language. Different areas of the site have different languages and there's no common language which could be used as a master language in the whole site. Also it should be possible to create the initial content in any language, so the workflow should be automated/transparent instead of the default master language one.

Unfortunately it is too hard to actually implement this correctly in midgard-core. It is too hard to actually have multiple fallback languages. That's because the internal SQL queries must return only the best matches (the MultiLang is basically impemented in SQL level) and adding more fallback languages to the queries would complicate them a lot... (I wasn't sure if it's impossible but at least it would be very complicated to do and doing it would risk introducing new hard to solve bugs.)

It seems the best practical way to solve this is to just automatically copy the content to all site's languages. I first tried to copy the best matching content to lang0, which worked, but deleting the objects become impossible then (MidCOM doesn't understand that even though the content is only in lang0, it should be deleted from langX so that when content is gone, the fallback is also gone as otherwise the content would just show indefinitely - the actual delete would have been possible to implement but the problem was toolbar and components which couldn't of course understand that they should provide the delete links/forms...). I implemented it as an external feature but for easier usage and better maintenance, it should be added to MidCOM itself.

This unfortunately can't be a component because default_lang needs to be set very early in the request to make sure everything works correctly in all circumstances. Well this *can* be a purecode component (or a similar watcher could be implemented but that would not handle deletes automatically) of course but then its usage requires multiple lines of code (would be almost the same as not having this in MidCOM). Easiest usage requires that this feature is a midcom.core service which is added to midcom_config and activated automatically in midcom.php when enabled. This is not something absolutely necessary to have in midcom.core but it seems having it there is the best option (I bet the code is simpler this way than as a component - also this code is simpler/shorter/faster and more bullet-proof than if the same functionality is done as a watcher - with this code this basically goes straight to Midgard API and therefore belongs to midcom.core). This is purely a new feature and if this is not used, the *only* line of code being executed is the check for its midcom_config setting (one if clause which checks if the setting has something or is false/empty).

Change History (135)

comment:1 Changed 7 years ago by jval

  • Resolution set to fixed
  • Status changed from new to closed

(In [24971]) Add automated/transparent MultiLang? workflow support with multiple fallback languages, fixes #1626

comment:2 Changed 7 years ago by jval

(In [24972]) Parameter domains use dots, use here too, refs #1626

comment:3 Changed 7 years ago by jval

Actually automated lang0 syncing (using lang0 as a fallback where best match is placed) would have also been possible if deletions would have been per language only and last langX delete would have always deleted full objects (possible with action_delete and action_deleted callbacks).

I tried to create the workflow in a way deletes affect full objects and that was impossible with that syncing solution because MidCOM can't see the object in langX if object doesn't have a langX translation. Well, not fully impossible as it would have worked from languages where translation exists. (It would have been a bit unclear but it would have worked in practice because translation would exist in practice in those cases usually.)

If someone actually needs that kind of workflow, we can add new method(s) to the class for that purpose. You know, we now have "auto" workflow but we could also have e.g. "lang0" workflow in the future.

Now that I think about this, it seems there are multiple different kind of workflows which are possible. There are at least two different kind of fallback handling possibilities (in addition to the built-in one). Then there are at least two different kind of delete handling possibilities (delete only translation vs. delete full object).

Some of the workflows would require a bit more complex code to be written. For example when deleting a full object, it should always be done in a way its children are all also deleted as full objects (otherwise the database is left in a state where there are active objects without parents). Normally midcom.admin.folder (and Asgard) handle those recursive deletions but in this case as the delete workflow would be different/special, it would have to be handled in the workflow itself I guess. (The "lang0" workflow would need this kind of solution in both delete handling cases because that workflow would not have all translations in the current language in all situations.)

Clearly implementing all possibilities would take a bit of time. I guess it makes no sense to do it without actual real life need. If there is a need it's quite fast to implement a new worklow to the class then because it's just one workflow then in question.

It seems the worklow I ended up implementing is indeed the simplest one. We need no special delete handling code because the language always has all the objects visible and all objects are deleted recursively in normal MidCOM operations.

comment:4 Changed 7 years ago by jval

(In [24976]) Add multilang auto workflow support to fi.protie.navigation's untranslated CSS class handling, refs #1626

comment:5 Changed 7 years ago by jval

(In [24977]) Use the service's own get_lang() because we want to get the empty string instead of null in lang0 case (lang0 usage is discouraged but this way it should work if used), refs #1626

comment:6 Changed 7 years ago by jval

  • Resolution fixed deleted
  • Status changed from closed to reopened

I think I need to reconsider the implementation of deletes because it seems it adds difficulty a lot when lang0 is not used. You know, page elements etc. don't function like you'd assume because they are normally in lang0 and setting default_lang masks them. (Actually I still got style working but root topic was strangely found but incorrect...) Of course we could put everything into correct lang but I don't like the idea of duplicating everything because of this. It might make more sense to handle lang0 a bit similarly as SG0 is handled regarding the sitegroups functionality.

Reopening to state it clearly that this feature/ticket is not yet finished. Implementation (and even behavior) might still change a bit. I need to make some tests and decide what is the best implementation.

comment:7 Changed 7 years ago by jval

(In [24978]) Don't change default_lang but instead change lang to default_lang when deleting (same end effect but allows lang0 to be used like SG0 is used with sitegroups), refs #1626

comment:8 Changed 7 years ago by jval

(In [24980]) Add generic get_default_lang() and use it, refs #1626

comment:9 Changed 7 years ago by jval

(In [24982]) Rename reset_lang() to set_lang_back() because we actually want to return to latest lang (which needs to be set by calling set_lang_back() first) instead of initial lang (although in practice they are of course the same). Move set_lang_back() lower so that we have the event handlers ordered logically in the class. As set_lang_back() is now called always before it's used, remove reset_lang() call from the auto workflow method as it's no longer needed. Refs #1626

comment:10 Changed 7 years ago by jval

  • Resolution set to fixed
  • Status changed from reopened to closed

Ok, this implementation seems to work and is still simple (and simpler to use than the original one). Feature is complete.

comment:11 Changed 7 years ago by jval

I realized that if delete fails, lang is left to lang0. I thought about it and it seems it's still better this way because this solution solved a real life problem and that problem is more like a theoretic one.

It's theoretic because this version of Midgard doesn't check for privileges internally except for sitegroup boundary crossing. Basically delete can fail only if the object doesn't really exist or is somehow corrupted. MidCOM checks all those cases before it tries to delete objects so in practice we shouldn't ever get to the point where delete fails internally.

I also thought about whether it is better to change lang to default_lang or the other way and it seems the current implementation is better because lang0 is used for the actual site and langX for content. It is a much bigger problem if the site's language changes than if content language changes. (Because if site language changes, MidCOM's finish stage would not be executed.)

Although this is not perfect it seems this is the best solution in practice. This ticket itself is a solution which is the best in practice but not perfect. :)

comment:12 Changed 7 years ago by jval

  • Resolution fixed deleted
  • Status changed from closed to reopened

It seems using default_lang like SG0 is used with sitegroups (master one which can control everything) is not something which can be relied on.

I guess it should be done the other way then: default_lang should be changed to lang before delete() and back afterwards. (This means lang needs to be set back also because of the way set_default_lang() works.)

Even though I wrote above that doing it that way might be a bit problematic it shouldn't be an issue in real life.

Reopening because feature is not complete yet because of this. It works with current Midgard version but should be changed so that it works with future versions as well.

comment:13 Changed 7 years ago by jval

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [24995]) Change delete implementation, fixes #1626

comment:14 Changed 7 years ago by jval

r25397 should have referred here

comment:15 Changed 7 years ago by jval

(In [25572]) Behave correctly in language context delete conditions also when the multilang auto workflow is used. Refs #1736, refs #1626, refs #1659, refs #1620

comment:16 Changed 7 years ago by jval

(In [25665]) Fix mistake done in r25572. Refs #1736, refs #1626, refs #1659, refs #1620

comment:17 Changed 7 years ago by jval

(In [25819]) Call dbfactory->is_multilang() only once to speed things up. The multilang_auto_langs check is supposed to be inside the non-ML block especially because we do want to apply the ML block's checks. In the multilang_auto_langs check, allow delete only when Midgard language is part of multilang_auto_langs. Refs #1736, refs #1626, refs #1659, refs #1620, refs #1775

comment:18 Changed 7 years ago by jval

Should have referred here:

comment:19 Changed 7 years ago by jval

(In [26160]) Add multilang auto workflow support to midcom_services_metadata's populate_meta_head(), refs #1626

comment:20 Changed 7 years ago by jval

(In [26163]) Code styling changes, refs #1626

comment:21 Changed 7 years ago by jval

(In [26170]) Make re-attaching actually work, refs #1626

comment:22 Changed 7 years ago by jval

(In [26171]) Correct the file version information line, refs #1626

comment:23 Changed 7 years ago by jval

(In [26183]) Document the multilang auto workflow register method, refs #1626

comment:24 Changed 7 years ago by jval

(In [26186]) Have all multilang service related initialization code in the service itself for better code maintainability. Mention about connect_default() usage and the fact that the service has recerved its usage at least for now (it's the only one using it so no issues at the moment). Refs #1626

comment:25 Changed 7 years ago by jval

(In [26188]) Move object comparison to its own method, refs #1626

comment:26 Changed 7 years ago by jval

(In [26189]) File itself is documented, so note about that can be removed now. Mark the connect_default() note as a TODO item because it's not for users but for our selves. Refs #1626

comment:27 Changed 7 years ago by jval

(In [26196]) Better method parameter description, refs #1626

comment:28 Changed 7 years ago by jval

(In [26197]) Revert r26186 because it seems it would just cause chained method calls. Also this way the whole class isn't even loaded when it's not used. Refs #1626

comment:29 Changed 7 years ago by jval

(In [26202]) Add multilang lang0 workflow and recommend it over the auto workflow, refs #1626

comment:30 Changed 7 years ago by jval

(In [26209]) It's better to use langs from for consistency reasons ( is used already in the sync method). Let's use the original name for the workflow startup method and also support the original argument(s) so that the original API stays. The lang0 workflow is also automated and it's internally related with the auto workflow anyway so auto is ok as a startup method name. Refs #1626

comment:31 Changed 7 years ago by jval

Woups. :) I used $GLOBALS in the previous commit message and forgot to use single quotes when I committed... I meant to say there that we use langs from $GLOBALS.

comment:32 Changed 7 years ago by jval

(In [26212]) Add ticket URL to the comments, refs #1626

comment:33 Changed 7 years ago by jval

(In [26228]) Check the parameter also when multilang_lang0_langs is used because multilang_auto_langs can still be enabled elsewhere (e.g. in other lang host or even just at other path as the setting can be defined dynamically in site's code), refs #1626

comment:34 Changed 7 years ago by jval

(In [26229]) Only touch the langs entry if it exists. Don't add languages which aren't included in the workflow. Refs #1626

comment:35 Changed 7 years ago by jval

(In [26230]) Move the domain variable to the syncs method so that syncs can be called externally without having to know the domain value. Refs #1626

comment:36 Changed 7 years ago by jval

(In [26231]) Make update the default event for the syncs method so that it's easier to call syncs externally for an object, refs #1626

comment:37 Changed 7 years ago by jval

(In [26232]) Add support for changing the multilang lang0/auto workflow configuration afterwards, refs #1626

comment:38 Changed 7 years ago by jval

(In [26233]) Handle non-multilang objects correctly, refs #1626

comment:39 Changed 7 years ago by jval

(In [26234]) Use array_pop() to get rid of already processed objects so that less memory is needed for the operation, refs #1626

comment:40 Changed 7 years ago by jval

(In [26235]) Use guids instead of objects so that less memory is needed for the operation, refs #1626

comment:41 Changed 7 years ago by jval

(In [26236]) Return also the guid of the object itself so that the array contains all processed guids, refs #1626

comment:42 Changed 7 years ago by jval

(In [26237]) Remove the guid collecting because it doesn't reduce memory usage. Use array_pop() to get rid of already processed objects and set memory_limit to unlimited while processing. This one at least works. Refs #1626

comment:43 Changed 7 years ago by jval

Don't change from auto to lang0 just yet. The syncing doesn't handle that properly yet.

I think both workflows work ok and even work together but if you change from auto to lang0 it doesn't work properly yet because existing parameters aren't deleted at the moment.

comment:44 Changed 7 years ago by jval

(In [26238]) Don't check the parameter if auto workflow isn't applied for the object. Also, for the same reason, remove possible parameter when deleting a translation. Refs #1626

comment:45 Changed 7 years ago by jval

(In [26239]) Don't sync when object wasn't translated, refs #1626

comment:46 Changed 7 years ago by jval

(In [26240]) Support lang0 as one of the languages. Also, add support for moving from auto/lang0 workflow to disabled mode (the default lang0 as a master language workflow). Refs #1626

comment:47 Changed 7 years ago by jval

Changing from auto to lang0 is now working. It should now be possible to change between all three workflows (lang0, auto and the default one with one master language) and their combinations.

The idea with configuration changes is that you need to sync the language hosts then with: /midcom-exec-midcom/multilang.php

That needs to be run in all hosts and in reverse preference order. (Or in some special cases even in some other order. You need to think about how it works and then you know the correct order to run.)

comment:48 Changed 7 years ago by jval

(In [26241]) Sync also the symlink target, refs #1626

comment:49 Changed 7 years ago by jval

(In [26242]) Create lang0 content in lang0 workflow if it's missing, refs #1626

comment:50 Changed 7 years ago by jval

(In [26243]) No need to pass lang0 as false in the array so let's use the normal conversion method, refs #1626

comment:51 Changed 7 years ago by jval

(In [26244]) Fix r26228, refs #1626

comment:52 Changed 7 years ago by jval

(In [26250]) Document about special case when you need to define lang0 to multilang_lang0_langs to get everything behaving consistently, refs #1626

comment:53 Changed 7 years ago by jval

(In [26251]) Add a new script called multilangs.php which syncs all languages in one go - and correctly, refs #1626

comment:54 Changed 7 years ago by jval

(In [26253]) Fix r26251, refs #1626

comment:55 Changed 7 years ago by jval

The lang0 workflow is not ready yet. It works with the current Midgard delete implementation but should be improved so that it's safe with future versions of Midgard as well.

comment:56 Changed 7 years ago by jval

(In [26262]) New methods set_lang_to_object_lang() and set_lang_back() which are useful with the lang0 workflow, refs #1626

comment:57 Changed 7 years ago by jval

(In [26263]) We need to always set the language anyway so add multilang to the check instead of returning, refs #1626

comment:58 Changed 7 years ago by jval

(In [26264]) Handle deletes properly considering the lang0 workflow. Set lang to object's lang before delete because with the lang0 workflow we're not always deleting the object from the same language. Refs #1626

comment:59 Changed 7 years ago by jval

(In [26265]) Only manipulate the behavior of delete when current language is part of the workflow(s), refs #1626

comment:60 Changed 7 years ago by jval

(In [26268]) I was about to make midcom_services_multilang Ragnaland friendly but I realized it's not even a good idea to make it silently fail. Having an ugly fatal error from PHP is actually better because that the user will notice. Inform the user about ML support dependency at the configuration setting description. Refs #1626

comment:61 Changed 7 years ago by jval

(In [26269]) Delete only non-translated content - not the fallback content, refs #1626

comment:62 Changed 7 years ago by jval

(In [26270]) The workflow can be started only once because it uses the global variables, refs #1626

comment:63 Changed 7 years ago by jval

(In [26276]) Cosmetic change to code comment, refs #1626

comment:64 Changed 7 years ago by jval

(In [26294]) Behave correctly even if default_lang!=lang0, refs #1626

comment:65 Changed 7 years ago by jval

(In [26295]) Handle theoretical move from lang0 workflow to auto workflow by deleting duplicate lang0 contents when lang0 content isn't used for anything, refs #1626

comment:66 Changed 7 years ago by jval

(In [26296]) Fix r26295: Only delete if object's content is from lang0. Refs #1626

comment:67 Changed 7 years ago by jval

(In [26297]) Instruct user to configure things in a more rational way, refs #1626

comment:68 Changed 7 years ago by jval

(In [26298]) Mention the obvious that default_lang needs to be lang0 when the lang0 workflow is used, refs #1626

comment:69 Changed 7 years ago by jval

(In [26299]) Correct the code comment, refs #1626

comment:70 Changed 7 years ago by jval

(In [26300]) Remove unnecessary check (if current language is lang0 at that point the previous check handles it anyway), refs #1626

comment:71 Changed 7 years ago by jval

(In [26301]) Cosmetic change: use same kind of code in try/catch as in is_object_equal_in_lang(), refs #1626

comment:72 Changed 7 years ago by jval

(In [26302]) Instruct user to run the multilangs.php script by default because that's the normal case and a lot more clear and easier/faster to use too, refs #1626

comment:73 Changed 7 years ago by jval

Ok, the new lang0 workflow and changing between auto/lang0/built-in should now work. New code is not yet tested but at least self-auditing the code is now done and it should be ok now.

So I made a workflow where fallback data is automatically put to lang0. That one is more standard and also better to use so that should be preferred for normal use cases when you need multiple fallback languages and transparent operation where all languages are masters.

comment:74 Changed 7 years ago by jval

Well I got some more ideas still about possible logical bugs. It works but some corner cases might not be just right ATM... Need to think about this still a bit. But it can be used already I think.

comment:75 Changed 7 years ago by jval

(In [26307]) Missing lang0 content needs to be created only when we remove untranslated content, refs #1626

comment:76 Changed 7 years ago by jval

(In [26308]) Delete untranslated content only when there's fallback content, refs #1626

comment:77 Changed 7 years ago by jval

(In [26309]) Make sure object has content in current lang before deleting duplicate lang0 content, refs #1626

comment:78 Changed 7 years ago by jval

(In [26310]) Split to generic methods, refs #1626

comment:79 Changed 7 years ago by jval

(In [26312]) Fix r26310, refs #1626

comment:80 Changed 7 years ago by jval

(In [26313]) Use the new methods, refs #1626

comment:81 Changed 7 years ago by jval

(In [26317]) Fix r26312, refs #1626

comment:82 Changed 7 years ago by jval

(In [26318]) Create missing current language content only when deleting duplicate lang0 content, refs #1626

comment:83 Changed 7 years ago by jval

(In [26319]) The auto workflow's duplicate lang0 content deletion logic needs to be executed for both translated and untranslated cases, refs #1626

comment:84 Changed 7 years ago by jval

(In [26320]) Fix r26319, refs #1626

comment:85 Changed 7 years ago by jval

(In [26321]) Delete untranslated content only when it actually exists in current lang and didn't come from fallback, refs #1626

comment:86 Changed 7 years ago by jval

(In [26322]) We can't skip the check when default_lang=lang0 because lang0 content might be missing and we naturally want to delete only translation and not full object, refs #1626

comment:87 Changed 7 years ago by jval

(In [26323]) Only create fallback content when we need it (tree sync handles things in general and object sync needs to handle only current lang), refs #1626

comment:88 Changed 7 years ago by jval

(In [26324]) The auto workflow's duplicate lang0 content deletion logic should be run only with the master content, refs #1626

comment:89 Changed 7 years ago by jval

(In [26325]) Fix r26321: We need to compare to current language and not to object's language which could be fallback too, refs #1626

comment:90 Changed 7 years ago by jval

(In [26326]) It's best that content in default_lang exists when translation is deleted, refs #1626

comment:91 Changed 7 years ago by jval

(In [26327]) Only delete untranslated content when fallback language is the same as what the workflow uses. It also removes the need for DB query about fallback content. That fixes logic originally introduced in r26308. Also only try to get lang0 content when it exists so we don't execute DB query when it's not needed. Refs #1626

comment:92 Changed 7 years ago by jval

(In [26366]) In lang0 and auto workflows, if master content is missing from current language and it's from lang0, create it to current language. This makes configuration changes between different workflows to work properly. Refs #1626

comment:93 Changed 7 years ago by jval

(In [26367]) Add complete support for changing between different multilang workflow configurations, refs #1626

comment:94 Changed 7 years ago by jval

The workflows themselves are simple but support for changing between them is a bit complex. :)

At least at the moment I think now there should be all features present which were needed. Time will tell if there are bugs. :)

comment:95 Changed 7 years ago by jval

(In [26371]) Complement/fix r26367, refs #1626

comment:96 Changed 7 years ago by jval

(In [26372]) Update flags also when deleting, refs #1626

comment:97 Changed 7 years ago by jval

(In [26373]) Fix r26367/26371: Pass correct content to sync() when it's needed and have only current language related code in sync() so moved lang0 deletion code to syncs(), refs #1626

comment:98 Changed 7 years ago by jval

(In [26374]) Fix r26373: Don't accept lang0 for default_lang when lang is lang0, refs #1626

comment:99 Changed 7 years ago by jval

(In [26375]) Fix r26367: Default should be workflow syncs of course, refs #1626

comment:100 Changed 7 years ago by jval

(In [26376]) Set correct value to variable even though it's not used after that, refs #1626

comment:101 Changed 7 years ago by jval

(In [26377]) Pass object in correct language to delete(), refs #1626

comment:102 Changed 7 years ago by jval

Okay, it looks and feels correct and ready now. The sync() method only handles current language (and lang0 in case of the lang0 workflow). Workflows themselves handle only their own languages. Handling other languages is now an extra task like it should be.

Code looks good "on paper" but requires testing. Use at your own risk at this point. :) I'll do some tests and fix possible issues / report here how it went.

Perhaps it's now ready but let's see how the tests go.

comment:103 follow-up: Changed 7 years ago by jval

Workflows themselves work ok according to tests. So existing sites using these workflows can upgrade to this latest code.

I still need to test configuration changes and multilangs.php execution.

comment:104 in reply to: ↑ 103 ; follow-up: Changed 7 years ago by jval

I still need to test configuration changes and multilangs.php execution.

Not working fully like it should... :)

comment:105 Changed 7 years ago by jval

(In [26378]) Don't process same languages twice, refs #1626

comment:106 Changed 7 years ago by jval

(In [26379]) Don't remove the parameter in lang0 workflow's detach if the language is also part of the auto workflow because auto workflow itself handles the parameter then, refs #1626

comment:107 in reply to: ↑ 104 Changed 7 years ago by jval

Not working fully like it should... :)

Fixed in r26379.

I still need to test configuration changes and multilangs.php execution.

Still need to do more tests regarding that. Workflows themselves are now pretty stable but I've not yet tested all possible configuration change runs.

comment:108 follow-up: Changed 7 years ago by jval

Found another bug related to configuration changing. It should be purely configuration changing related so actual workflows are safe.

It might be a bit tricky to fix though...

comment:109 Changed 7 years ago by jval

(In [26380]) Revert r26239: Sync needs to happen also when object wasn't translated because the language can be master one and changed content still needs to be synced to lang0/langs then, refs #1626

comment:110 follow-up: Changed 7 years ago by jval

That one was a bug in the lang0 workflow itself. Now fixed.

The configuration changing related bug is still there.

comment:111 in reply to: ↑ 110 Changed 7 years ago by jval

That one was a bug in the lang0 workflow itself. Now fixed.

In the auto workflow as well of course but as I said, now fixed. :)

comment:112 Changed 7 years ago by jval

(In [26381]) In auto workflow (at least in its current implementation) there's always a parent when there are multiple languages. Don't create the master language content in lang0 workflow if it's missing because lang0 is an unknown language and we can't know which language its content is in (and we don't need this because real translating does create the content). Do create master language content in auto workflow but mark it as automatically generated then. It can be fetched from any language because it's marked as automatically generated. Refs #1626

comment:113 in reply to: ↑ 108 Changed 7 years ago by jval

Found another bug related to configuration changing. It should be purely configuration changing related so actual workflows are safe.

...

The configuration changing related bug is still there.

Fixed in r26381.

comment:114 Changed 7 years ago by jval

(In [26388]) Multilang workflow configuration changing related fixes, refs #1626

comment:115 Changed 7 years ago by jval

(In [26389]) Use only automated language for automated language parent, refs #1626

comment:116 Changed 7 years ago by jval

(In [26391]) Fix loading of object, refs #1626

comment:117 Changed 7 years ago by jval

Okay, all issues noticed while testing are now fixed so both workflows and changing configuration works now.

The new lang0 workflow and configuration changing support will be in the next 8.09.9 version.

comment:118 Changed 7 years ago by jval

(In [26419]) Don't use object language as default_lang because we're getting suitable default_lang for translation deletion here, refs #1626

comment:119 Changed 7 years ago by jval

(In [26420]) Remove unnecessary code, refs #1626

comment:120 Changed 7 years ago by jval

(In [26421]) Check also if lang0 is part of auto languages, refs #1626

comment:121 Changed 7 years ago by jval

(In [26423]) Revert r26421 (we're not supposed to check that here because it's already handled earlier), refs #1626

comment:122 Changed 7 years ago by jval

(In [26424]) The sync() method already deletes the translation if its untranslated and lang0 exists. We must not delete it twice then. Refs #1626

comment:123 Changed 7 years ago by jval

(In [26425]) No need to use a separate variable for this so use the array instead, refs #1626

comment:124 Changed 7 years ago by jval

(In [26426]) Skip the block if lang0 is already marked for deletion, refs #1626

comment:125 Changed 7 years ago by jval

(In [26428]) Instead of trying to hack when to delete here, only execute sync() when we don't delete, refs #1626

comment:126 Changed 7 years ago by jval

So there were two fixes:

  1. Use correct language as default_lang (skips the same language) when deleting duplicate untranslated language content, so that the deletion happens every time.
  2. To avoid duplicate delete() calls (which can cause full object deletion instead of language content deletion), only execute sync() when syncs() is not going to delete the language content.

comment:129 Changed 7 years ago by jval

(In [26429]) Cosmetic changes, refs #1626

comment:130 Changed 7 years ago by jval

So I found out (one by looking at the code and other by testing) two more configuration changing related issues but they are now fixed and the fixes will be in the next 8.09.9 version.

The new lang0 workflow and configuration changing support are now stable and ready for production use.

comment:131 Changed 7 years ago by jval

(In [26441]) Don't process the object if it's not multilingual, refs #1626

comment:132 Changed 7 years ago by jval

Unfortunately 8.09.9 does not have properly working configuration changing support. You need r26441 for that to work. (I didn't notice it with my test server but production DB has more data and there the convert process just stopped and didn't work properly without the patch.)

The lang0 workflow in 8.09.9 is stable.

I've just converted auto workflow production DB to lang0 workflow DB (patched with r26441) and I'm using the lang0 workflow in production and it works fine.

If you don't need to convert 8.09.9 is ok but if you convert, patch with r26441 or wait for 8.09.10. :)

comment:133 Changed 7 years ago by jval

I can't yet recommend using the configuration changing (conversion) feature. I had to restore a backup because the conversion didn't work correctly when part of the site is symlinked from another tree. I don't yet know why and what's buggy there so be warned.

Using the workflows themselves is safe but don't try to switch between workflows unless you know what you're doing and know if it worked etc. and have backups in case it fails on your case too. :)

comment:134 Changed 7 years ago by jval

(In [26448]) Only mark language existing if also given object has content in it (safeguards from backend fallback bugs and from incorrect data given by user), refs #1626

comment:135 Changed 7 years ago by jval

It was backend issue after all but r26448 safeguards from it so I can say conversion works now.

Note: See TracTickets for help on using tickets.