View calendar in page's current language

Thanks Nick for the idea.

I tested your patch #2 by following steps:

1. Edit the view.
2. Select 'Language selected for page' as the default language.
3. Save the view.
4. Switch the language for my Drupal site to '简体中文' (Simplified Chinese)
5. Back to the calendar page.
6. Clear the cache
7. Hard refresh the calendar page (force reload all js)

The language for the calendar didn't change to the site language which is Simplified Chinese.

The problem is that the language code for Simplified Chinese in Drupal is 'zh-hans', but FullClandar uses 'zh-cn' instead.

We need to figure out a way to synchronize the language code between Drupal and FullCalendar.

Thanks again for the idea and your patch.

Here's an updated patch that maps any lang codes shared by Drupal and FullCalendar but use different codes.

Here's one more that fixes the language on the generated URL paths. Really there should be a variable to store the link value instead of guessing in the template but that should be a separate issue.

Work for me with Spanish, English, French, and Deutsche.

Thanks. Works fine in Portuguese, Portugal.

Thank you all for your works on this issue.

The Version 3 of this module introduces a new plugin type that provides an ability to add additional logical to the view preprocess.

I just created a plugin for it and commit to 8.x-3.x branch as you can see above.

3.x release:
https://www.drupal.org/project/fullcalendar_view/releases/8.x-3.x-dev

I am using latest 3.x-dev and and still encountering this issue. Tried applying patches from #5 and #4 but they won't apply, but I suppose that may be because those patches got included in the 3.x-dev release.

In my view's Filter Criteria I have "Content: Translation Language" set to Arabic, and the Rendering Language (from the Language section of the view) is also set to Arabic. I have also tried setting those to the 'content language selected for page' and "Interface text language selected for page' but those don't work either. The events simply show in English.

If I set the 'Full Calendar Display' view format's "Default Language" to "Current active language on the page" the Arabic events are linked to the correct Arabic URLs, but the title and description still show the English translation, not the Arabic translation.

When I change my view display to 'Unformatted List' it shows the correct Arabic translation.

The language code Drupal uses for Arabic is "ar", and fullcalendar also uses "ar" for Arabic, so I don't see why that wouldn't work.

I just added a patch (#14). I have tested this and this works on my end.

My fullcalendar's Default Language option is set to 'Current active language on the page'. If I set that to any language other than my site's default language it will just show the default language, though. At least now I have it showing the correct title and description when Default Language is set to 'Current active language on the page'.

Ultimately I think this will require a rework of FullcalendarViewPreprocess.php, rather than the current workaround in CurrentLanguage.php. As long as you use 'Current active language on the page' for fullcalendar's "Default Language" option, this should work, though.

Thanks @Casper.

Yes, from the performance and simplification point of view, it is not ideal to put the translation logic into a plugin as the multi-language feature is one of the core features of this module. In order to provide an example of a process plugin introduced by 8.x-3.x, let's leave it as it is for now. I will put the logic for translation back to FullcalendarViewPreprocess at some point.

I create a new patch based on yours from #14 with following changes:

• A language has the same code as Fullcalendar, such as "ar", we don't need to convert it by fullcalendar_view_map_langcodes.
• Check if the translation for the current content exists to avoid a fatal error.
• Remove the hardcode field name of description field.
• Support custom text for a field.

Here is the new patch.

If you could test the patch for me in your use case, that would be good.

Thanks again.

Thanks @Mingsong. I tested your patch from #16 and that worked for me.

The patch #16 works as required. Thanks for the patch. It was very much required.