Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2015-07-05 05:39:33

ax
Member
From: Germany
Registered: 2009-08-19
Posts: 144

Re: Public-side multi-lingual URLs

Bloke wrote #292578:

But anyway, that’s all very well and good until search engines go down, then URLs become important

Get real. When should this happen? In an apocalyptic movie? Textpattern users will survive, thanks to their ingenious URLs?

But if the URL doesn’t matter, why do search engines give it such high status?

I seriously doubt that google ranks an image higher if it is referenced in it’s native language, and what is the native language of an image anyway?

And why do news sites use keyword stuffing techniques in the Title?

SEO? No. This does not affect articles. With permanent link mode set to /section/id/title, it is all in your language, and beyond Textpattern’s control (well, except the id).

Offline

#12 2015-07-05 06:49:36

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 1,546
Website

Re: Public-side multi-lingual URLs

For the (average) end-user, the URL is just a black box, except maybe for the domain name. Like Peter (Ax) I personally don’t think it is worth the effort to localise those special URL’s. And BTW, you can’t have nice category1 or category2 in your URL when you run TXP in CJK languages (and other non-roman languages, I think) [1]. So on that count, I’m leaning towards option 1 (that might mess up /category URL’s on one of my sites, but I don’t worry too much about that, those URL’s are no-index anyway; might need some htaccess magic for end users – bookmarked URL’s).

Now, if you are thinking about a truly multilingual site (same articles in multiple languages) then an URL-structure of the type example.com/de/category/category_name probably might make some sense at organisation level. But you need to go further, and include example.com/jp/section/article-title and so on. Apple.com uses that scheme at all levels.

PS – Here is another one that is messy for the end-user: run Textpattern in Japanese; for category you’ll get URL like this /カテゴリ/foo/ (aka /category/foo). Displays fine in the location bar. If you bookmark that page in Safari and have look at your bookmark manager, the url is displayed as is. Now try that in Firefox – you get /%E3%82%AB%E3%83%86%E3%82%B4%E3%83%AA/foo Nice and useful eh?

I think search engines will show you /カテゴリ though. But I seriously doubt they give much weight to having that part of the URL localised. What matters, for the URL, is the article-title if present in the URL.

– – –
[1] What we do for a Japanese site is have the category_name romanised (as in : ringo with category_title “林檎”) and the whole site runs on messy URL.

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,458
Website

Re: Public-side multi-lingual URLs

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?


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

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

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 1,546
Website

Re: Public-side multi-lingual URLs

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.

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,458
Website

Re: Public-side multi-lingual URLs

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.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

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

gaekwad
Member
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 2,379

Re: Public-side multi-lingual URLs

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.

Offline

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

maverick
Member
From: Southeastern Michigan, USA
Registered: 2005-01-14
Posts: 959
Website

Re: Public-side multi-lingual URLs

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)

Offline

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

redbot
Plugin Author
Registered: 2006-02-14
Posts: 1,410

Re: Public-side multi-lingual URLs

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 ;)

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,458
Website

Re: Public-side multi-lingual URLs

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?


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

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

redbot
Plugin Author
Registered: 2006-02-14
Posts: 1,410

Re: Public-side multi-lingual URLs

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)

Offline

Board footer

Powered by FluxBB