Skip to content

fixe Invalid translation language #1176

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

Closed
wants to merge 0 commits into from
Closed

Conversation

bachy
Copy link

@bachy bachy commented Mar 3, 2021

fix issue #1175
just applied the same fix as #652

@pmelab
Copy link
Contributor

pmelab commented May 25, 2021

Continuing the conversation from #647 , the three options provided by @Pasqualle :

  1. Return the source language
  2. Return null
  3. Return Drupal's language fallback

In most cases 1 and 3 are identical i think, but 3 will cover more ground if the language fallback is modified. I'm not sure if it wouldn't even be better to return null (option 2) in API use cases. So the consumer has a clear indication and can implement fallback logic itself. Do we have any opinions and/or use cases?

@Pasqualle
Copy link
Contributor

Pasqualle commented May 25, 2021

To comment on #647 (which was for v3 version of graphql module):

Before #647, the module returned an error with no content.
Drupal (with default language fallback) displays the content in source language, so I have implemented option 1 (with small code improvements) as a quick fix.
I think the PR was merged without discussion.

The PR had 2 issues:

  1. it changed the display behavior of untranslated content
  2. implementing option 3 would have been more aligned with Drupal's logic.

I think the best solution would be to implement a new language fallback logic in Drupal for graphQL. So the language fallback logic can be different for Drupal backend and for the frontend app (graphql consumer). Then depending on the use case frontend can choose (can configure in Drupal) to display or not display the untranslated content, regardless of Drupal's fallback logic.
I would prefer to have the consumer's language fallback logic defined in Drupal, than to write it in the frontend app. That would make the frontend app much cleaner.

@Kingdutch
Copy link
Contributor

I too would like some more configurability. I'm personally debating whether we need a global fallback or whether we need something on a data producer level. In v3 I think the global fallback makes sense because the API does a lot for you. However, in v4 we can not make assumptions about how data producers are used so I think a setting may make more sense.

I can think of a scenario (1) where a client requests data without specifically specifying a language (for example an overview) in which case it'd be desirable to have the content in the clients default language with a fallback to the site's default language.

Another scenario (2) may have a client fetch data for translation or as display in a specific language. In that case a NULL result to indicate such a translation does not exist may be far more useful than retrieving a fallback language.

@klausi klausi added the 4.x label Aug 16, 2021
@bachy
Copy link
Author

bachy commented Sep 19, 2022

months later i had to redo the entire debug process to finally find i already submitted a pull request to resolve this issue ...
can't we commit the fix please, as the bug is blocking (internal server error) and then discuss on adding some feature.
please

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

Successfully merging this pull request may close these issues.

5 participants