Problem with &context=image in dev 4.6

jakob · 2016-01-29 23:04:47

In a site converted from 4.5.x to 4.6 links of format /index.php?s=section&c=category-name&context=image have stopped working. The same basic code works 4.5.x but in v4.6 it always returns a 404.

After much searching, it seems to be because the site language is set to German. Set the language back to English and it works again. But in 4.5.x it works in German. I think it is due to this line in publish.php which uses a localised string context_image to check what a valid context is. Set the language back to German and use &context=Bild and it works…

Has the code changed since 4.5.x or has the context_image string only recently been localised? Does it make sense to localise category context at all?

philwareham · 2016-01-30 08:56:49

This may be to do with the language translations, there are a few strings called:

article_context
file_context
image_context
link_context

Only thing I’ve noticed different about the German and English strings for this (apart from the translation) is that the English is all in lowercase whereas the German had a capital letter. I’ve just made that lowercase now, can you update your language, test again and let me know fi that fixes the problem?

jakob · 2016-01-30 12:20:47

philwareham wrote #297648:

I’ve just made that lowercase now, can you update your language, test again and let me know if that fixes the problem?

Thanks Phil. That helps in that it makes the url all lowercase, but you still need to use the localised string in the url, i.e. &context=bild instead of &context=image. I’m assuming that if the code in publish.php always used the localised string in the past, those four language strings were not previously translated.

My question is: In this particular situation, changing txp’s language setting breaks functionality. Is that wise? For example, if in future we have templates, they will break if someone changes to their own language.

Perhaps one solution that allows both localised url strings and maintains functionality would be to amend the validContext function to allow both the english strings article, image, file, and link as well as the localised strings. This does it, for example, but there may be a more elegant way of doing that:

function validContext($context)
{
    foreach (array('article', 'image', 'file', 'link') as $type) {
        $valid[gTxt($type.'_context')] = $type;
        $valid[$type] = $type;
    }
    return isset($valid[$context]) ? $valid[$context] : 'article';
}

PS: This (for me) was really hard to debug as the url throws a 404 so I couldn’t do tests to see what part of the code was being reached because the relevant form/page isn’t run. In the end I looked at the txp code on github to try and see what was happening. It was only by chance that I saw that gTxt function in there and twigged what was happening.

wet · 2016-01-30 13:30:36

This touches a sensitive item we have never expressly clarified: Should URL parts be localised?

We have a few informal precedences: The ‘section’, ‘category’ and ‘author’ URL parts have been localised since the early gamma versions of Textpattern: An English site would link to http://example.com/category/hope-for-the-future/ while the German site would link to http://example.com/kategorie/hope-for-the-future/.

The disadvantages are obvious: Changing the site’s language from the preferences or, even worse, a heedless change in a language file will break links to previously perfectly valid URLs.

I don’t think that translators added localisations to the four new URL part strings (‘article_context’, ‘image_context’, ‘file_context’, ‘link_context’) when contexts where initially introduced.

It would break URLs which existed since Textpattern 4.4.0 if anyone changed the translations of these four context strings now or in the future.

I’d like to hear Stef’s opinion as the context-related code is mainly his contribution and he has also intentionally introduced the code snippet in question.

colak · 2016-01-30 15:37:49

wet wrote #297654:

It would break URLs which existed since Textpattern 4.4.0 if anyone changed the translations of these four context strings now or in the future.

I should do a comparison of the files for the greek translation as I have translated about 98% of all english strings to greek

jakob · 2016-01-30 16:30:12

Thanks for the feedback. That echoes with what I thought.

wet wrote #297654:

It would break URLs which existed since Textpattern 4.4.0 if anyone changed the translations of these four context strings now or in the future.

I think this is what has already happened. If you look here (http://rpc.textpattern.com/lang/de-de.txt) and search for image_context, you’ll see:

image_context => bild

and so on for the other cases. I’m not sure how to compare against earlier language file versions, so I don’t know how long this has been the case, but if I were the one translating those strings, I wouldn’t have known to ignore that particular string and leave it in English. So even if we did reset that string back to English now, it could easily be “heedlessly changed” again in the future. Hence my suggestion above to always permit the English-language variant in all cases, but to allow people who want to use a localised version to do so if required. I would suggest extending that to /section/… /category/… and /author/… too if that’s not already the case.

There’s still potentially a problem for multi-language sites, but as txp doesn’t support multiple languages out of the box, it’s not really a core problem. I’d probably then revert to the english code and do an url rewrite to cover the different language variants.

jakob · 2016-02-06 13:08:16

Stef, can I bump this onto your radar?

Bloke · 2016-02-06 13:30:16

Sorry I missed this first time round. The reason for the localised language strings in the URL was because, as Robert pointed out, I was following our previous protocol of doing it for section and category. This I now realise, with the benefit of hindsight, was probably a mistake. As was the original decision to use localised URLs for section and category.

There was a thread a few months ago that touched on this and I think the consensus was that localised URLs were a bad idea for a CMS, especially when phiw13 mentioned the atrocities that get rendered in Japanese, for example.

So we’re faced with a choice. Stick with it and live with it and tell people with multi-lingual sites not to translate the contexts (ever) or go back and remove localised support for URLs. That may be considered a deal-breaker for a lot of sites and not suitable for a point release, but I’m willing to drop support for localised URLs now if it’s for the good of our long-term goals.

Thinking forward, my goal for 4.something is to offer some form of multi-lingual experience. Whether that be the ability for a proper plugin (not a hack, like MLP) or for out-of-the-box multi-lingual capabaility I don’t know, but either way writing content in more than one language leaves us with a dilemma. Let’s take an example. You write an article in English: The horse is a problem. It’s translated into a new German article: Das Pferd ist ein Problem. Today we would have URLs a bit like this (assuming fictional multi-lingual support in URLs):

example.org/en/article/the-horse-is-a-problem
example.org/de/artikel/das-pferd-ist-ein-problem

The article URL title is dumbed down if necessary, but still in the local language, as is the ‘article’ section. If we go with non-local URLs, then we’d not only lose the localised section but we’d also have to change the way our article URLs are generated for multi-lingual content so the URL would become:

example.org/de/article/the-horse-is-a-problem

i.e. the url-title is based on the ‘parent’ article of the base language. Quite how that works if your base language is German and you write Das Pferd ist ein Problem first I have no idea. Ideas welcome! Alternatively we go with mixed stuff, leaving the core routes in English and the article title itself in the local language (but note the dumbed-down version may contain strings of percent-encoded character entities):

example.org/de/article/das-pferd-ist-ein-problem

What I’m trying to get at is that this decision affects a lot of plans for multi-linguality, and how the core behaves depending on the number of languages installed, and the order in which they are installed (or which one is designated ‘master’). So I’d like to get it right, whatever form “right” takes.

Last edited by Bloke (2016-02-06 13:41:36)

Textpattern CMS

Textpattern CMS support forum

#1 2016-01-29 23:04:47