Link abstraction breaks relative links between languages

[teppokoivula]

Short description of the issue

If CKEditor enabled field (note: this likely affects regular Textarea with HTML content type as well) has link abstraction HTML option enabled and user inserts a link to the same page but in another language (i.e. from /fi/tietoa-meista/ to the same page in default language, /about-us/), link abstraction seems to replace this with a link to current language version when viewing the page.

Expected behavior

Link abstraction should not modify links from one language to another — or at least I can't really see how this would be intended behaviour.

Actual behavior

Link abstraction modifies links.

Steps to reproduce the issue

1. On a multilingual website, edit Textarea Language field with CKEditor and link abstraction HTML option enabled
2. Add a link to the same page in the default language from non-default language
3. Open the site — link should now point to the same language instead of the default language version

Setup/Environment

• ProcessWire version: 3.0.148
• (Optional) PHP version: 7.2

[ryancramerdesign]

@teppokoivula The intention is that default language links update to current-language links when the linked page is available in the user's current language. This is because in most cases, translated pages are not available all at once, so they have to link to default language pages by necessity; typically because the page being linked to just hasn't been translated yet (translation being a gradual process). Most of the time this is a desirable behavior, and I think many installations may depend on this behavior as well. I'm not sure I understand the use case for not having it, unless building a language switcher in CKEditor or something. Though let me know if I'm missing something, which is certainly possible. Currently, the way it can be overridden is to use a full url link with scheme and hostname.

[teppokoivula]

Thanks @ryancramerdesign!

I think I kind of understand what you're saying, but I'm still having a bit of trouble understanding why this is preferable. Let's say that you only have the English version of your "About us" page available — why would you link to the Finnish version in the first place? And if you did link to this (non-existing) version, would it really be preferably for that link to be modified run-time so that it points to current page instead of where it originally pointed?

I'm probably missing something here. This is one of the very few sites that I've built using full language support instead of just language fields, and I've been pretty confused by some aspects of it :)

I'm not sure I understand the use case for not having it, unless building a language switcher in CKEditor or something.

The use case here is that the client wants to add a custom link to the same content in another language. One example of this is a case where they have a page with limited amount of content in Swedish, and then an explanation that more content can be found from the Finnish version (and an in-context link to that).

This site also has a language switcher, so this is not the only way to navigate between languages, more about providing users (and particularly screen reader users) a convenient way to quickly move between language versions.

Currently, the way it can be overridden is to use a full url link with scheme and hostname.

This is actually something I try to steer our clients away from. It's a bit of a nuisance if the domain of the site ever changes, it has different implications for SEO (admittedly this is a very minor reason), and (in our case) perhaps most importantly the site is not publicly available in the "final" domain until it goes live, and this would very likely leave us with a ton of links to the development domain.

If you think that changing this behaviour is out of the question, then I'm fine with that decision, though I kind of wish that it was at least configurable (without removing link abstraction entirely, which is what I've done for now).

Thanks again for taking the time to reply and consider this, much appreciated! :)

[teppokoivula]

... and now that I've re-read your post, I think I got it: presumably this (page linking to itself in another language, and this link getting modified so that it points to literally the same URL you're currently browsing) is more of a side effect than a real goal?

I mean... I can understand why might want a link from page A to page B point to page B in the default language in case page B is not available in the specified language. That being said it feels like quite a border case, in my opinion, and may be confusing to the user (language changes suddenly), even though it does make more sense than "correcting" a link to point to itself :)

Still wondering if this would be something that could be made configurable, or if there should be a way to tell ProcessWire that "yes, I really, really want you to link to this page in the language I've specified" :P

[jacmaes]

I've run into the same issue, as described in this forum post, when trying to link to the same page but in a different language. With "Link abstraction" turned on, I was stumped (and pretty frustrated) as to why I was being redirected always the same page on the current language when clicking on the link on the front-end.

The use case, I think, is pretty common: if there's no translation available on a particular page, or there's more information available in another language, we need to be able to add a link to the same page in another language to inform users. Turning off "Link abstraction" solves this issue, sure, but we lose all the good things that come with this useful option.

This points to a larger issue: there should be an easy way to select another language from the tree. Right now, unless I'm missing something, clients just can't link to a page from another language from a CKEditor field.

[romaincazier]

Something like this could be useful:

It's just a mockup as I couldn't simply try by myself. Quickly scanning the code, I think it would involve quite some changes, mostly in the js part, and it would need a complementary input behind the scene specifying the language along with the page ID.