Language issues on system pages & pagelist macro #310

New issue

Open

opened 2020-05-08 15:48:14 +00:00 by matthijskooijman · 0 comments

matthijskooijman commented

2020-05-08 15:48:14 +00:00

(Migrated from github.com)

Recently, we did some language-related cleanups (e.g. properly splitting content and interface languages) and I think that language selection works rather well for normal pages now.

However, for system pages, there is no unified way to specify a content language. This is intentional, since:

Not all system pages actually show content, so need a content language.
Because system page urls start with their name, rather than the language, you'll never have a conflict when a normal page has the same name as the system page.

Instead, system pages are free to add a language selection as arguments after their name, if they need it (e.g. /tag/en/foo).

However, I noticed some issues:

The page index now generates urls like /en/index and [expects $O_O->getContentLanguage() to be set correctly] when rendering the index. Effectively, this means that all language-links in the index result in a 404. Fixed by #311.
The tagindex now handles an added language properly for resolving the taglabel in the right language, but when it then tries to render the pages, they are rendered using $O_O->getContentLanguage(). Since that is unset for system pages, that will just fall back to the default content language instead. Then, if the page does not exist in that language, an error is thrown.

Issue 1. is probably easy to fix by just accepting the language as a second argument.

Issue 2. is a bit more involved. I think that this would involve the content language to be set for system pages as well. Since each system page might have its own url structure, we cannot do this generically, so it must be done inside the datatype class. Adding the following code to tagindexpage::tagindexview() works, but that's not so nice (it abuses the fallback language, I think):

                   $lang = $request->getArg(0);
                    $this->O_O->setFallbackLanguage($lang);

Should there be a setContentLanguage() maybe?

A second way to look at this issue is that when instantiating an datatype class, you can only pass the page list node, but not the language to be used (that is implied to be $O_O->getContentLanguage()). This is currently acceptable (with the above fix), since the tag index page will only return pages tagged with a tag in the selected language, which implies that these pages are available in the same language as well.

However, when generalizing this page list (e.g. as part of #87), you might end up rendering other pages that are not available in the same language. You might want to then specify the language to use explicitly, or maybe make sure that there is a fallback in place (if a page is not available in the requested content language, fallback to the site default or an arbitrary language?).

There might be other related issues in other system pages maybe?

Recently, we did some language-related cleanups (e.g. properly splitting content and interface languages) and I think that language selection works rather well for normal pages now. However, for system pages, there is no unified way to specify a content language. This is intentional, since: - Not all system pages actually show content, so need a content language. - Because system page urls start with their name, rather than the language, you'll never have a conflict when a normal page has the same name as the system page. Instead, system pages are free to add a language selection as arguments *after* their name, if they need it (e.g. `/tag/en/foo`). However, I noticed some issues: 1. ~~The page index now generates urls like `/en/index` and [expects `$O_O->getContentLanguage()` to be set correctly] when rendering the index. Effectively, this means that all language-links in the index result in a 404.~~ Fixed by #311. 2. The tagindex now handles an added language properly for resolving the taglabel in the right language, but when it then tries to render the pages, they are [rendered using `$O_O->getContentLanguage()`](https://github.com/PlanBCode/hypha/blob/52b865f3d766c2bedf00a2ed80a2210d6ed81088/system/core/pages.php#L80). Since that is unset for system pages, that will just fall back to the default content language instead. Then, if the page does not exist in that language, an error is thrown. Issue 1. is probably easy to fix by just accepting the language as a second argument. Issue 2. is a bit more involved. I think that this would involve the content language to be set for system pages as well. Since each system page might have its own url structure, we cannot do this generically, so it must be done inside the datatype class. Adding the following code to `tagindexpage::tagindexview()` works, but that's not so nice (it abuses the fallback language, I think): $lang = $request->getArg(0); $this->O_O->setFallbackLanguage($lang); Should there be a `setContentLanguage()` maybe? A second way to look at this issue is that when instantiating an datatype class, you can only pass the page list node, but not the language to be used (that is implied to be `$O_O->getContentLanguage()`). This is currently acceptable (with the above fix), since the tag index page will only return pages tagged with a tag in the selected language, which implies that these pages are available in the same language as well. However, when generalizing this page list (e.g. as part of #87), you might end up rendering other pages that are *not* available in the same language. You might want to then specify the language to use explicitly, or maybe make sure that there is a fallback in place (if a page is not available in the requested content language, fallback to the site default or an arbitrary language?). There might be other related issues in other system pages maybe?

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#310

No description provided.

Rows
Columns