Discussion Forum

florianuhlemann

Member

From: Germany

Registered: June 26, 2015

Posts: 21

Website

Localization Plans

Hey there,

I've been trying to figure out how to implement a bilingual version of my website with BigTreeCMS. (I just love it too much to go any other route)

Goal is:

website.com/en/imprint
website.com/de/impressum
alternatively: website.com/en/impressum

ideally, the plage slugs would be localized as well, but linked through canonical tags. if not possible or too much work, I'd just use the German slugs (German company, legal reasons make German the preferred slug language)

Had a few Ideas:

1) use .htaccess to remove /en and /de from link and add it at the end? template then reads it and either plugs in German or English title/content.
2) create a module that has 2 entries, en and de, and forward any slug after it to the actual page (might cause /imprint to be readable as well as /en/imprint with the same page as a result)
3) modify all routing so that the CMS system uses the second path item instead of the first one and create a first one being the variable for language. Preferred solution I guess, but seems to be the hardest for me.

Admin Frontend would be in such a way that a template includes the title and content fields for both languages and the template detects which language is active from the path/url sub-part and parses only the correct language.

Curious on your ideas,
Florian

timbuckingham

Administrator

From: Baltimore, MD

Registered: April 2, 2012

Posts: 978

Re: Localization Plans

The easiest way is definitely duplicating the page tree at /en/ and /de/ and using BigTree's multi-domain setup to serve things from website.com.de and website.com (if you own both domains). Otherwise I'd probably serve website.com's main page tree as your primary language and then just move people to /de/ or /en/ for the secondary tree.

Your plan for modules sounds good to me and if you want to force everything into the default language via htaccess (and only have /en/ and /de/ as top level pages) that could work as well. I'd definitely avoid overriding core (#3) if possible which means you will need to duplicate the whole tree for separate languages. As you mentioned with a single page tree and a custom routing solution you could store the content for each language in its own field. That could make back-end administration easier but in the long run it could be bad for maintaining core updates.

Another option could be to create a custom routed template that you use for your top-level pages at /de/ and /en/ that looks up the custom routes provided (e.g. /en/about/contact/ will take /about/contact/ and look for a page in bigtree_pages with that path) and manually does the routing. Obviously that's MUCH easier if you're not using any other routed templates in the site. Serving up basic templates pretty much will amount to getting the entry from bigtree_pages, translating your content_en and content_de fields to just "content" and then including /templates/basic/whatever.php for the template. You can also use BigTree's routing methods to serve routed templates this way as well it's just a bit trickier. If you set $bigtree["page"] back to the page you looked up and use "trunk" on /en/ and /de/ you should be able to safely use built-in BigTree methods like getBreadcrumb and and getNavByParent without much trouble.

florianuhlemann

Member

From: Germany

Registered: June 26, 2015

Posts: 21

Website

Re: Localization Plans

Thanks for the feedback. Did some coding before I went to sleep and ended up doing a mix of #2 and your suggestion.

The basic template includes a self check, if its first path element is en or de. If not, redirect to en and use its current first path element as the new second. This will get a little messy with many templates, but I could move it to a separate PHP file and just include it in any template at the beginning.

Now my routed template with the module kicks in. It gets the page ID from its slug name, verify that the page actually exists and throws 404 if not. It then gets the template used by the page, includes the template PHP file and prepares the resources to be used by the template.

All cases are covered with basic templates, additional routed templates might cause trouble, but could be addressed similar to the first self check as used in basic templates (to prevent website.com/imprint to be accessible)

With the custom checks I could also make it possible to use a translated version of the slug to be used for URL. I'll see how I end up writing the checks for those...

No htaccess used, this stuff just kills me if it gets too complicated ?.

Localization was planned for 5.0 milestone, eh? Curious how that will be solved

Last edited by florianuhlemann (April 2, 2017 9:19pm)

timbuckingham

Administrator

From: Baltimore, MD

Registered: April 2, 2012

Posts: 978

Re: Localization Plans

Sounds like you were thinking the same thing as me for the most part! Glad you've got some stuff working.

BigTree 5.0 does include localization support but for the admin side (mostly through 1:1 string translation) and not the front-end. Front end localization is planned for the future, though. We've had very limited bandwidth to push (and BigTree 4.3 has been delayed so long now that it's become 5.0) so it definitely won't make the next release but it is something I'd like to see implemented soon!

Degnan

Member

Registered: November 2, 2017

Posts: 1

Re: Localization Plans

Sounds like you were thinking the same thing as me for the most part! Glad you've got some stuff working.

BigTree 5.0 does include localization support but for the admin side (mostly through 1:1 string translation) and not the front-end. Front end localization is planned for the future, though. We've had very limited bandwidth to push (and BigTree 4.3 has been delayed so long now that it's become 5.0) so it definitely won't make the next release but it is something I'd like to see implemented soon!

Awesome to hear that front end localization is in the works. Any news on that front?

Last edited by Degnan (November 2, 2021 6:08pm)

timbuckingham

Administrator

From: Baltimore, MD

Registered: April 2, 2012

Posts: 978

Re: Localization Plans

Unfortunately, work has been very slow on 5.0. Front end localization is still a ways off!