following use case:
I have a website with currently three configured languages:
German (default)
English
French
The site displays a periodical publication; the issues are organized into books (one book per issue).
The journal contains articles in a language chosen by the author (can differ from the ones configured, ie be in Spanish, Portuguese etc), therefore for the time being these are set to language neutral. Hence i18n Book Navigation will include those nodes in every hierarchy it re-creates.
However the prefaces are currently in German and English, but are not translated to French yet. So if I set the node languages accordingly, visitors who default to the French interface will not see those nodes since there is no translation in the current language; all they see are the language neutral nodes).
Therefore a fallback to the default (or a configurable) language IF the original node is in the book outline, but no translation exists, would be a great feature.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | i18n_book_navigation_check_current_language.patch | 737 bytes | nfavrod |
Comments
Comment #1
wadmiraal commentedI see your point. But does Drupal allow you to do this in a clean way ?
IOW, is it possible to have, say, a menu link point to a page in a different language (e.g. 'fr') than the current one (e.g. 'en'), have the link displayed and when clicked, keep the current language ('en') in session and not switch to the other language ('fr') ?
In D6, we had a lot of different language handling methods for i18n (simple, mixed, default, etc). The 6.x version of i18n Book Navigation was built on that and does what you're asking for.
However, with the new i18n Select in D7 module, you only have 2 modes: yes or no. So i18n Book Navigation uses this for it's logic as well.
I would rather not add such a specific use case to the module if there's no way to replicate the behavior in Drupal. But maybe I'm mistaking: is there a way in Drupal 7 to set a "fallback" language like in Drupal 6 ? This could actually be very useful in several cases. If so, then I'd consider this a "bug", because the i18n Book Navigation module must completely integrate with i18n and should not have to be configured.
Comment #2
bbbo commentedI wish I'd better understand how it works... but I guess the problem lies with the way paths and links are constructed.
I'm not using i18n Select since it messes up my views (which do allow mixed language content).
Acually I think the use case won't be that rare, since many scientific publications contain articles in various languages which are not consistently translated so one has to agree on one default language that covers all articles.
I'll try to dive deeper into this topic once I have the site running, for now I just workaround by copying the English content into the French translation nodes.
Entity translation BTW does have it's own fallback mechanism which works with paths constructed from the interface language independently of the content language since it's still the same node, just different field content. It just does not work with book outlines so far...
ET documentation has a bit on that.
Comment #3
wadmiraal commentedHmm, I'll have to check a bit further. Again, I'm not favorable of adding settings to this module, as it's primary goal is to bridge the gap between i18n and Book, not to add functionality on itself. If there's really no other way though, I might consider it.
I was really surprised when porting this module to D7 about the lack of options in i18n Select. I think the D6 options were far better and allowed for more flexibility (although the settings could get quite confusing).
As for ET, there is another feature request here: #1416166: Work with Entity Translation, which I haven't looked into yet.
Comment #4
bbbo commentedI agree the i18n Select options are sparse; perhaps the feature request should go there; I'm also rather disappointed by the lack of flexibility in language configuration in general.
Entity Translation is an interesting alternative, but since it works on field level probably not trivial to integrate.
For now the workaround with copied content works and it's only for a couple of nodes; but for the future I'd really wish there was a clean solution in core Drupal or core i18n.
Will look into this again later.
Thanx anyway for your module and your efforts.
Comment #7
nfavrod commentedHello,
I found that there was a "bug" when the original node language is not the same as the book language.
By example, I had in the middle of the book a page that was pointing to the wrong language.
It doesn't solve the issue with "non-translated nodes"..
Here's the patch attached. Please check and review!
Comment #8
wadmiraal commented@nfavrod
Thanks. It's on dev :-). Next time though, you might want to open a new issue, so if other people get here they don't get confused by the thread. If you have any other questions or encounter issues concerning your patch, please open a new issue so we can discuss it there.
Kind regards
Comment #9
wadmiraal commentedMarking as postponed. This has been open for a year now, and I still haven't gotten into this. I'm still pondering on how to implement this in a clean way as well...
Comment #10
wadmiraal commentedNo activity in 3 years. Closing.