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
Multilingual Options #259
Comments
The new secondary task functionality could likely be modified to handle this. Currently, it assumes a "member of" relationship, but we could make the specific type of membership between the primary nodes and the secondary nodes an additional config option, so for example if you wanted the translated nodes as in your case you'd specify that relationship.
|
Not having much luck determining if creating proper node translations via REST (or JSON:API) is possible. The only issues I can find that discusses this functionality are https://www.drupal.org/project/drupal/issues/2135829 (core REST) and https://www.drupal.org/project/drupal/issues/2794431 (JSON:API) and it's not clear to me what their status is, despite both being pegged to Drupal 9.2. I'll continue to research. |
@DonRichards, As a long shot I just tried using an I checked in with the first issue linked above, and there have been no updates to the issue other than to postpone it again until Drupal 9.3.x-dev. This version was just released today but I can't find any indication that entity translations via REST are included in it. Unfortunately, I don't think Workbench can currently do what you're asking. |
Hi @mjordan - I wondered about the level of effort required to enable multilingual import (in my specific case, metadata that has already been translated and so we have the English and French versions). We have an existing client in this situation, and two more multilingual sites coming up over the next 6 months. |
If I am understanding https://www.drupal.org/project/drupal/issues/2135829 and https://www.drupal.org/project/drupal/issues/2794431, none of the HTTP APIs Drupal currently offers support creating proper translations. In response to your question "a", probably not a lot, but as for "b", whenever one of those two Drupal core issues is resolved. The most recent comment on the first issue is from 2 years ago, and the most recent substantive comment on the second one is from 6 months ago. So this functionality doesn't appear to be a very high priorty for the general Drupal community. So, I am happy to have Workbench support creating multilingual nodes, but it can't until Drupal's HTTP APIs can. |
Got it - thank you for that explanation, it's very helpful! |
I'm sorry I can't offer a more postive response, but Workbench is constrained by what Drupal's HTTP APIs can do. |
@mjordan Would this help at all? This looks like a multilingual migration test if I'm not mistaken. This could be worth reviewing I guess. https://github.com/drupal/drupal/tree/8.3.x/core/modules/migrate/tests/modules/migrate_external_translated_test |
I found it from these suggestions https://drupal.stackexchange.com/a/229746 The suggestion looks like it "should" work but who knows |
Migrate doesn't use HTTP APIs (as far as I know), so I can't see any relevance Migrate has here. But I could very well be missing something, since I don't know Migrate that well. |
Oh, well in the description they point to a migration that does a multilingual migration. Here |
I don't know - if there's a way to populate that structure via an existing HTTP API, this might work. I'll take a look. |
@mjordan The main requirement is that the translation needs to be available before a PATCH request is sent. If the translation is available, then one can use the translation endpoint to patch it. Example:
In the comment linked above, they intercept the request and create the translation. This can potentially be done via the integration module. Note that the language tag may not be needed |
@Natkeeran thanks, that looks promising. I'd rather keep the Integration module simple in that it enables the Views, etc. required for basic communication with Workbench, so would prefer to see this code in a separate and optional submodule. The main reason for this is not technical, it's about my increasing inability to maintain larger, more complex modules. At any rate, let's see if this works; if it does, we can discuss how we package it. |
I've put the logic into a small module here: https://github.com/digitalutsc/rest_translation_util Mainly intending to support PATCH. |
Wow - let me kick its tires! |
Tested with basic fields and taxonomy terms by id. Taxonomy term by value will need additional logic to lookup and create. |
Moving this here from Slack - let me know if you'd like it to be its own issue:
|
Adding @dara2's note from the Slack conversation that "these warnings have to do with 2 terms that were set the same in English and in French: “Text” and “Collection” (“Text” should really be “Texte”)'. |
Suggestion:
To accommodate multilingual content by means of 2 migrate CSV files; 1 with the bulk of the fields with the original language content and other with another with just overrides. Assuming both nodes reference the same 'id' field or something. Trying to keep the 2 separate but avoiding having to keep duplicating all of the content like relaters and other metadata.
Original CSV
Overrides CSV
Backend could fetch the data from the other csv like which file to associate with the translated content
Resulting content for the first node for the 2nd language content.
In a nutshell:
In this example it has 5 nodes but in 2 languages resulting in 10 nodes, all of the fields will be applied to both language versions but the 2nd overrides the specified fields. And both language versions pointing to the same media/files
Is this possible to have workbench allow for this?
The text was updated successfully, but these errors were encountered: