Public-side multi-lingual URLs

Bloke · 2015-07-05 09:47:06

ax wrote #292581:

what is the native language of an image anyway?

I’m struggling with this idea in a multi-lingual Textpattern universe. If you upload an image for an English article and it’s translated to French on your site, we can add some UI fluff to allow the alt text to be translated, but are there situations when the image itself needs to be different for international audiences? Is it a case that sometimes the asset is shared, but sometimes it’s different? I don’t know, but it’s a question that has implications for how files and images are managed. Don’t want to store multiple identical assets, but don’t really want to limit the interface to force the same asset unless it’s reasonable to expect that if the image is different, a new one is uploaded with a different ID and then only the French alt text need be completed.

With permanent link mode set to /section/id/title, it is all in your language

Yeah, sorry, I was being dim. Title has nothing to do with this.

phiw13 wrote #292582:

you need to go further, and include example.com/jp/section/article-title and so on.

That’s a given, yes. Every URL on the site would have the language designator. Whether you display it is (possibly) up to you. But if we go with all-English trigger URLs then the language designator would probably need to be mandatory for multi-lingual sites.

/%E3%82%AB%E3%83%86%E3%82%B4%E3%83%AA/foo Nice and useful eh?

Yuk. It’s urldecoded and urlencoded, which probably accounts for Firefox (or our implementation) being lame in this regard.

If nothing matters except for the title, then cool, dropping international trigger URLs is fine by me. Saves hassle in my proposed multi-lingual implementation, as I was going to go float the notion of internationalised section names too so it looks nicer in search results.

The overriding sentiment so far seems to be that nobody sees an issue with backwards compatibility on existing sites, nor cares what the URL reads. Great. Saves work and doesn’t affect me anyway as I’m a monoglot. Just didn’t want to barrel ahead without due consideration if international URLs were of value. It seems not, and they cause more problems than they solve.

Going further, and being ever so slightly facetious for a moment, I don’t entirely buy Apple’s decision to phase out the URL from the end user experience. What next: hide the URL endpoint in emails from “your bank” so you have no idea if the link you’re going to click is legit or a phishing attempt? After all, the URL holds no value, right?

If the URL is deemed pointless, why is everybody not using bit.ly links for their own site content? Guaranteed unique. Shorter to type and dictate. Or how about we forget the URL entirely and just move towards forcing messy mode? It reduces clutter in the UI (no clean URL or permlink modes to worry about), less configuration hassles with fewer things to go wrong, and it’ll make sites render faster because there won’t be layers of indirection to decode. Oh, wait:

The more readable by human beings, the better.
Keywords in URLs: still a good thing.
Exclude dynamic parameters when possible.

Surely therein lies the point?

phiw13 · 2015-07-05 12:00:21

Bloke wrote #292583:

Yuk. It’s urldecoded and urlencoded, which probably accounts for Firefox (or our implementation) being lame in this regard.

That is Firefox (bookmark manager) doing – I’ve seen the same thing on most sites that use non-latin characters in the URL.

…I don’t entirely buy Apple’s decision to phase out the URL from the end user experience. What next: hide the URL endpoint in emails from “your bank” so you have no idea if the link you’re going to click is legit or a phishing attempt? After all, the URL holds no value, right?

Slight exaggeration there? Safari only “hides” the (full) URL when the location bar is not focussed. And URL’s do hold value.

Bloke · 2015-07-05 12:20:08

phiw13 wrote #292584:

That is Firefox (bookmark manager) doing

Glad to know it’s not just us then.

Safari only “hides” the (full) URL when the location bar is not focussed

Oh, is this on mobile / tablet only? Doesn’t do that on my desktop version. In which case, that’s a design decision to save real-estate, which is perfectly acceptable. From the way ax was talking it seemed he was implying there was no value in the URL and that was why they got rid of it. Maybe I misunderstood. I don’t use Safari if I can help it.

gaekwad · 2015-07-05 17:50:38

maverick wrote #292580:

Symphony does unlimited custom fields out of the box (every field is a custom field), and has multiple multi-lingual extensions. So we ended up going with Symphony. I’m in the middle of learning it.

I’d be curious to hear how you get on with Symphony, particularly if the XSLT stuff is a help or a hindrance.

maverick · 2015-07-07 03:21:04

gaekwad wrote #292597:

I’d be curious to hear how you get on with Symphony, particularly if the XSLT stuff is a help or a hindrance.

I’ll post an update once I’m closer to wrapping up the project.

I understood the basic concept of xml fairly well going in to the project. I found out I didn’t understand name spacing very well (I get the what they are doing, and why, just not the why it is constructed the way it is). xPath is quite easy and useful. XSLT itself has a bit of a learning curve, and I’m still wrestling with it. I’ve not gotten into XQuery very much as of yet. Not sure if I’ll even need it. Together, they seem pretty powerful though.

So far it seems the XSLT does a lot of things of the things we use plugins for in Textpattern – specially processing in the process of templating and publishing. Iterating over variables for example.
Their ability to capture events on the front side and process them into the database is nice.

It reminds me a bit of the Textpattern learning curve – you tend to struggle with it and then one day the light goes on and after that it gets much easier. :)

Last edited by maverick (2015-07-07 03:22:35)

redbot · 2015-07-07 11:26:48

Hi all,
I’m back with a really stupid and completely off-topic proposal, I hope you will forgive me.
I recall my first requests back in 2006 were about the introduction of subsections in txp, and I have always been amazed by the fact nobody seemed to care.
Coming to the point, other than reducing greatly the time spent on building a site, I think this feature could have a nice side-effect when building not-too-complex multilingual sites, given that with subsections one could create, let’s say, 3 sections named en, es, it and voilà, a basic multi-laguage site is done.
Ok, I said it, now you can ignore this useless post ;)

Bloke · 2015-07-07 12:21:53

redbot wrote #292730:

subsections in txp, and I have always been amazed by the fact nobody seemed to care.

“Care” vs “Damn, that’s hard to do without breaking everything” are not the same thing :-)

with subsections one could create 3 sections named en, es, it and voilà, a basic multi-laguage site is done.

Presumably you mean as ‘top level’ sections, with repeated sections beneath each?

en
-> About
-> Articles
-> Contact
it
-> About
-> Articles
-> Contact
es
-> About
-> Articles
-> Contact

?? If so, that’s far from ideal as there’s a lot of duplication of Sections. If you change one language structure by adding a Portfolio section, you need to change the layout in three places.

A multi-lingual site is normally that structure inverted:

About
-> en
-> it
-> es
Articles
-> en
-> it
-> es
Contact
-> en
-> it
-> es

But the language switching capability does not necessarily benefit from content being in their own physical sections. Rather, the URL designates which of the three sets of translations (renditions in MLP parlance) are displayed in the same, single structure. It’s just switching content, not switching section: the URL helps to disambiguate which route to take and ensures endpoints are unique for search engines/bookmarks.

I suppose it’s semantics though. The content could be written in its own Section but you’d need to go about creating the language tree each time you add a Section. A hassle. Having “virtual” sections for each language’s content means less configuration overhead. Unless I missed your point?

redbot · 2015-07-07 13:12:27

Bloke wrote #292738:

..Unless I missed your point?

Hi Bloke,
it was kind of you to take the time to reply to this absurdities
Anyway no, you didn’t miss my point. It was really a shallow request ;)

Last edited by redbot (2015-07-07 13:16:58)

ax · 2017-03-03 00:20:51

Just stumbled upon this problem again. After having changed the currently active language on the admin side from English to German, all URLs with “&context=image” were broken and threw a 404 error. Only recognized this a couple of days later, and it took a while to locate the problem. Yes changing the respective form to “&context=bild” would restore the website. But why? Who cares about the URL? It should be possible to change the admin language without destroying the website, in my opinion. Thanks for reading.

Bloke · 2017-03-03 08:53:07

ax wrote #304341:

It should be possible to change the admin language without destroying the website

In 4.7.0 it will be. Admin language and front-side language are treated as separate entities. Phase one of bringing multiple-language site support to core.

It doesn’t fix the language-sensitive URLs, unfortunately, but we’ll address that in future versions. Maybe we’ll go back and make everything English URL strings at the expense of backwards-compatibility, or permit both for a few versions so people can adjust, or keep them as they are and just manage it better so it’s more transparent. No decision has been drawn yet: it’ll depend on us weighing up the pros and cons of each approach.

etc · 2017-03-03 09:06:43

ax wrote #304341:

Who cares about the URL?

Many people, unfortunately. We are slaves of SEO.

ax · 2017-03-03 09:17:00

etc wrote #304354:

Many people, unfortunately. We are slaves of SEO.

Correct, but SEO likes URLs that would not change (as per language settings for example), and prefer readable buzzwords, such as “image” (better than “bild”, I assume). Therfore, I would vote for freezing the English language into the URLs. It does not affect a whole lot of keywords anyway.

Bloke wrote #304349:

weighing up the pros and cons of each approach.

What about having a voluntary advisory board for questions like this?

Textpattern CMS

Textpattern CMS support forum

#13 2015-07-05 09:47:06

Re: Public-side multi-lingual URLs

ax wrote #292581:

phiw13 wrote #292582:

#14 2015-07-05 12:00:21

Re: Public-side multi-lingual URLs

Bloke wrote #292583:

#15 2015-07-05 12:20:08

Re: Public-side multi-lingual URLs

phiw13 wrote #292584:

#16 2015-07-05 17:50:38

Re: Public-side multi-lingual URLs

maverick wrote #292580:

#17 2015-07-07 03:21:04

Re: Public-side multi-lingual URLs

gaekwad wrote #292597:

#18 2015-07-07 11:26:48

Re: Public-side multi-lingual URLs

#19 2015-07-07 12:21:53

Re: Public-side multi-lingual URLs

redbot wrote #292730:

#20 2015-07-07 13:12:27

Re: Public-side multi-lingual URLs

Bloke wrote #292738:

#21 2017-03-03 00:20:51

Re: Public-side multi-lingual URLs

#22 2017-03-03 08:53:07

Re: Public-side multi-lingual URLs

ax wrote #304341:

#23 2017-03-03 09:06:43

Re: Public-side multi-lingual URLs

ax wrote #304341:

#24 2017-03-03 09:17:00

Re: Public-side multi-lingual URLs

etc wrote #304354:

Bloke wrote #304349:

Board footer