Search

So... I was working with the language_redirect and multilingual_field extensions, but they don't do lang stuff the way I like. I'm super stoked that they're in place, but I changed the flavor just a little, and here is a lil package..

http://www.trimeragroup.com/ and http://www.krista-swim.com/ are good examples of how this should function. It's meant to be seamless and unobtrusive.

Basically this is how languages function using this..

  • It will read the browser preference and present whatever the user has set as their language.
  • If a user clicks a link, a cookie is set with JS lang, and that cookie will last for a year as the language they have selected (PHP doesn't set cookies).
  • The content is selected based on this.
  • If there is no content for an area it will show up as blank.
  • If a user doesn’t have a language that we have set ( french for example ) then it will default to the first language in our list ( you can change easily ) it is currently German.
  • Oh yah.. and it won’t route the user to a different URL like the extension used to do. The extension would turn http://x.com/thing/ into http://x.com/en/thing/ or http://x.com/de/thing/but not with this..

Super untested, but here goes nuthin
https://github.com/kirkstrobeck/multilingual-my-way

I'll try to keep it functional, so let me know if you see any problems

So, it basically does what i keep on doing in my projects :).

Difference is that i use Language field, one data-source to decide the language and output parameter, and then rest data-sources are filtered by their languge field values and this parameter.

I just prefer to have separate entries for separate language versions - so multiple authors/translators can work on them at the same time.

Like you, i also do not like redirecting to "/lang/paths". I think it is better to either keep the same URL and/or translate URLs ("/articles" and "/artyku?y" instead of "/en/articles" and "/pl/articles").

I love the lang tabs that the multilingual_field brings to the table, so this takes advantage of those, but lets me execute it the way I like, not sure what you do in your projects @ahwayakchih

Instead of multilingual field tabs i keep language versions in separate entries. In future, when it gets more stable, i will also try Subsection Manager tabs (to have best of both worlds: tabs and data in separate entries :).

With my current implementations, if one requires to have translations "connected" with each other, they can be "glued" through Subsection Manager or Bi-Link fields. I used Bi-Link field in one of projects before. In my current project we do not need translations to be connected at all (they kinda are, through another section's entries, but it was not required :), so it was much easier to implement.

I like your way of setting cookie with JavaScript, i think i'll use it as additional thing for all those that do have JS enabled (most of users).

@into: Usign different URL for different languages crucial for SEO. Google and other SE won't be able to see your site in different language and your content will be indexed only in one language, which is pretty bad.

wow, hadn't considered that.. great point

Nitriques, yeah, that is one of the reasons why it is good to have translated URLs (other one being better readability for users :).

@ahwayakchih: SEO is essential! Users rarely check URLs, but your PageRank is directly related to them!!!

Nitriques i know, but it is nice to have URL in native language at the same time :). I am not SEO expert, but i suspect that words used in URL can have some impact on page rank (especially if they can be found in page content) - similar to the use of "meaningful" titles.

@ahwayakchih: Url (including domain) + title + h1 tag + content is the way to go for SEO, so you have to translate them .... always.

It is not mandatory to have a /lang/ handle in the url, as long as their are reachable from different urls, in the good language.

Nitriques, thanks for information :).

@ahwayakchih: You're welcome!

It would be great to switch up the original extensions so they operate as apple.com does. The default ( first listed in symphony prefs ) language isn't shown in the URL.. only secondary languages are.

@into: Yes, this would be a super nice feature. I have been playing around with the Language Redirect Ext and may implement it in the near future since it is a requirement for one of my projects.

But remember that this gives your main language more importance than the other one since they are not at the same level in the url tree. If your page rank is 5, all your other languages will automatically be 4 since they are a level deeper.

Awesome, please keep me posted and email kirk@weareinto.com if you happen to develop it. It would be amaz for my current project. Thanks for your help in vetting my current approach !

@into: I will !

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details