Festival: translation of contributions and some other improvements #341

Open

matthijskooijman wants to merge 12 commits from festival-translation into master

matthijskooijman commented

2020-09-01 16:01:39 +00:00

(Migrated from github.com)

This PR also has code for other things that are currently in use on expokeerpunt.nl, but not merged here yet: An about page, customizable headers above the timetable and lineup and showing some command buttons to non-logged in users. Also, the first three commits here come from #340, so can be ignored here.

Some caveats I found while implementing this:

Translatable contributions and a customizable contribution form are a bit tricky to combine. A customized contribution form needs to describe the complete form, hardcoding pretty much everything with no room for dynamic content. This means that to translate a contribution, there are now just two different language versions of the "add/edit contribution" form, that you can switch between just like with translated pages. This works, but might not be ideal UI. Some way to include multiple translations in a single for (maybe with a tabbed UI or so) might be nice, but that's hard to combine with the hardcoded form customization we use now.
Categories are also tricky. I now chose to translate these, that is, each language stores its own category, in the local language. This makes displaying the category easy, since each language has a display-ready, translated version of the category. It does mean that the category between multiple languages might become inconsistent, and it is hard to programmatically do something with the category (since the same category will be named differently in each language). It also means that different languages might offer different category selections, which could maybe be a feature (though likely just adds confusion). One way to fix this would be to store categories as separate objects, link each contribution to one category object and give each category object a separate title for each language (but a single name or id, to allow referencing it in code or CSS).
Any fields that are not set for a translation, default to the value from another translation (looked at per-field, so you can translate one field and leave another empty). This seemed like a good idea, but in practice this just means that any time you edit a translation, all (empty) fields will be prefilled with a value from another translation (which is convenient for the first translation), but are then explicitly set to that value when saving (i.e. duplicating a value if unchanged). This is not a big deal, but might mean that I can simplify the implementation again to just use values from only the current translation (not looking per field if it is non-empty and doing a fallback to another language if it is), unless the current language has no translation at all, then it still needs to fall back to another language.
Fallback currently means: Use the selected language, or the first one in the XML file otherwise. This probably needs to use a bit of a smarter priority order, similar to the order used for interface language.
The interface language is currently not always determined by the content language, the user language and browser-requested language have more priority. This can mean that a visitor or user selects tot see a specific language, but still sees interface elements / language strings in another language. This is particularly weird when non-customized forms are used, because then the user can select a different language for the form, but nothing changes. This is something to reconsider, but changing this affects all of Hypha, not just this part.
When a custom form is provided in any language, the default autogenerated form will not be used anymore, even when no custom form is available in the selected language (i.e. it prefers a custom form in the wrong language over a non-custom form in the right language). This is probably ok, but maybe should be reflected in the language selection UI.
A lot of the translation-related code should really be made more generic and reusable (e.g. getTranslatedAttribute and friends).

I did some rough work to make contributions translatable. We discussed doing this along with #131 (external event datatype), but for simplicity and speed, I've just done the translations, still storing them inside the festival page XML, cutting some corners to make this usable for Expo Keerpunt first. This PR also has code for other things that are currently in use on expokeerpunt.nl, but not merged here yet: An about page, customizable headers above the timetable and lineup and showing some command buttons to non-logged in users. Also, the first three commits here come from #340, so can be ignored here. Some caveats I found while implementing this: 1. Translatable contributions and a customizable contribution form are a bit tricky to combine. A customized contribution form needs to describe the complete form, hardcoding pretty much everything with no room for dynamic content. This means that to translate a contribution, there are now just two different language versions of the "add/edit contribution" form, that you can switch between just like with translated pages. This works, but might not be ideal UI. Some way to include multiple translations in a single for (maybe with a tabbed UI or so) might be nice, but that's hard to combine with the hardcoded form customization we use now. 2. Categories are also tricky. I now chose to translate these, that is, each language stores its own category, in the local language. This makes displaying the category easy, since each language has a display-ready, translated version of the category. It does mean that the category between multiple languages might become inconsistent, and it is hard to programmatically do something with the category (since the same category will be named differently in each language). It also means that different languages might offer different category selections, which could maybe be a feature (though likely just adds confusion). One way to fix this would be to store categories as separate objects, link each contribution to one category object and give each category object a separate title for each language (but a single name or id, to allow referencing it in code or CSS). 3. Any fields that are not set for a translation, default to the value from another translation (looked at per-field, so you can translate one field and leave another empty). This seemed like a good idea, but in practice this just means that any time you edit a translation, all (empty) fields will be prefilled with a value from another translation (which is convenient for the first translation), but are then explicitly set to that value when saving (i.e. duplicating a value if unchanged). This is not a big deal, but might mean that I can simplify the implementation again to just use values from only the current translation (not looking per field if it is non-empty and doing a fallback to another language if it is), unless the current language has no translation at all, then it still needs to fall back to another language. 4. Fallback currently means: Use the selected language, or the first one in the XML file otherwise. This probably needs to use a bit of a smarter priority order, similar to the order used for interface language. 5. The interface language is currently not always determined by the content language, the user language and browser-requested language [have more priority](https://github.com/PlanBCode/hypha/blob/309d86e61890afaf49a5860be7be5dae5ee29f60/system/core/RequestContext.php#L121-L127). This can mean that a visitor or user selects tot see a specific language, but still sees interface elements / language strings in another language. This is particularly weird when non-customized forms are used, because then the user can select a different language for the form, but nothing changes. This is something to reconsider, but changing this affects all of Hypha, not just this part. 6. When a custom form is provided in any language, the default autogenerated form will not be used anymore, even when no custom form is available in the selected language (i.e. it prefers a custom form in the wrong language over a non-custom form in the right language). This is probably ok, but maybe should be reflected in the language selection UI. 7. A lot of the translation-related code should really be made more generic and reusable (e.g. getTranslatedAttribute and friends).

This pull request can be merged automatically.

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin festival-translation:festival-translation

git switch festival-translation

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch master

git merge --no-ff festival-translation

git switch festival-translation

git rebase master

git switch master

git merge --ff-only festival-translation

git switch festival-translation

git rebase master

git switch master

git merge --no-ff festival-translation

git switch master

git merge --squash festival-translation

git switch master

git merge --ff-only festival-translation

git switch master

git merge festival-translation

git push origin master

No reviewers

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

harmen/hypha!341

No description provided.

Rows
Columns