Public-side multi-lingual URLs

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?

etc · 2017-03-03 09:30:23

ax wrote #304355:

I would vote for freezing the English language into the URLs.

+1, if a bw-compatible way is possible.

jakob · 2017-03-03 09:57:43

I admit to not having read the entire thread, but I do think there are some cases where it is good to have localised urls, for example /author, /category etc. Currently I do this via htaccess.

Bloke · 2017-03-03 10:22:44

ax wrote #304355:

SEO likes URLs that would not change (as per language settings for example)

Maybe. The vagaries of search engine’s algorithms remain a mystery. In terms of language designators, I sort of agree. My initial draft when I started thinking about it was that having /en, /jp, etc in the URLs wasn’t much use. As long as the <html> tag has an appropriate lang attribute, search engines can figure out the language and index accordingly. Not having a visual URL designator makes things a whole lot simpler (in some ways) but more tricky in others. But it’ll largely depend on how we implement multi-lingual content.

Having localised URL components such as /category, /author, etc, I still don’t know. Part of me thinks it’s a nice-to-have. Part of me wishes I’d never followed the original Txp paradigm when I introduced context for the other content-types. It works fine for most Western languages, but looks terrible in browser bookmarks when they urlencode, for example, Japanese URLs.

Somewhere there’ll be a solution that satisfies most people, I just haven’t stumbled upon it yet.

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

You mean, like a forum ;-)

Destry · 2017-03-13 09:58:12

Bloke wrote #304359:

You mean, like a forum ;-)

+1

Textpattern CMS

Textpattern CMS support forum

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

#25 2017-03-03 09:30:23

Re: Public-side multi-lingual URLs

ax wrote #304355:

#26 2017-03-03 09:57:43

Re: Public-side multi-lingual URLs

#27 2017-03-03 10:22:44

Re: Public-side multi-lingual URLs

ax wrote #304355:

#28 2017-03-13 09:58:12

Re: Public-side multi-lingual URLs

Bloke wrote #304359:

Board footer