Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Multi-Lingual Site
Bloke wrote #329685:
I haven’t passed it on. Was waiting until you’d had a chance to play with the prefs tweaks I made and whether using Oleg’s suggestion for URL wrangling would cut down on plugin code needed (and hence development effort in future as our permlink schemes change).
Ah right. I haven’t had time as yet. Sorry.
TXP Builders – finely-crafted code, design and txp
Offline
Re: Multi-Lingual Site
No hurry. Just didn’t want to pass about untested code that wasn’t originally my own!
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
Re: Multi-Lingual Site
Very intriguing. I’m not sure if I’ve understood it all, but am I right in assuming this is the basic setup:
- txp sections with each language prefix (e.g. de and en)
- further txp sections for each language’s named section (e.g. ueber-uns, kontakt, … and about, contact,…)
- assign language sections to language prefix section (the “parent”) using adi_menu
- language lookup for a section by checking its adi_menu parent
- coupling of de+en sections via the same page template (e.g. a different page template for each section pair)
- coupling of de+en articles via a custom field holding the reciprocal article id
- language snippets as a set of txp variables loaded at page begin, then used throughout the page.
- use htaccess to set default language
Yes. You get all of that right. Thanks for claryfication.
And yes I did it how I did it because I tried to have less manual definitions involved.
One way to save the number of queries is to place some of those as page variables at the top of your page, and then use the variables in the rest of your page template.
In some places the hardcoded languages could still be replaced by some clever variables.
For example you could set the languages used in some kind of “basic configuration” variable.
Or this could be just taken once and automized by checking the “parent” sections of adi_menu.
I think this is more or less what you ment right?
One more thing: how have you dealt with things like image captions?
Damn! You got me on this one. =( Haven´t thought about it yet.
This will be tricky. Because when the whole multilanguage thing is connected with adi_menu then a plugin for image captions would also need to rely on on adi_menu, which seems not so elegant.
I would like to try to write a plugin that does that.
Those are my thoughts about it:
- Sh… It has been a while since I played around with plugin creation. Where to start? (I read all the docs this morning.)
- Wouldn´t it be more clever to create one plugin that does the whole job?
Which would mean:
- defining all languages needed and making them available in the section creation, so that in there you can define the “parent” for each section (like I do it with adi_menu now). Or even allowing the sections to “see” all installed languages in your txp install and by showing them in an extra select box on section creation you could easily define the parent (language) for each section.
- You would need have extra inputs for the image captions based on those languages.
- The “duplicate article” feature would be needed to group articles of the same content in different languages.
At the end this will be more of a solution for sites with a few languages (idealy 2) and small to medium sized amount of total articles. But that´s better than nothing.
I can also think of some grouping feature for the article list. So that articles with the same ID in custom_1 are grouped or cascaded in some nice way.
coupling of de+en sections via the same page template
I do not see such a problem here. At least for me personaly it is not a problem.
Because most of the time it is like that anyway. I rarely end up using the same page template for different sections anyway.
And I also do not have my page template in txp directly. I include them via php anyway to edit them in my editor. I am not sure if this would be called bad habit but like that I would be still able to use same page templates for different pages. Because the page template is different but the file that is included could still be the same.
Offline
Re: Multi-Lingual Site
demoncleaner wrote #329688:
Lots of interesting thoughts. Thanks!
One way to save the number of queries is to place some of those as page variables at the top of your page, and then use the variables in the rest of your page template.
…
Is this what you meant?
I really just meant that if you end up using some of your shortcodes multiple times in the same page template, you could store the result once at the top of the page as a txp:variable, then use that variable in your template so that the relevant queries are done only once. (But maybe txp/mysql caches already-made queries anyway?)
Image captions / you would need have extra inputs for the image captions based on those languages.
I used jcr_image_custom to create additional image custom fields and named them with a _de or _en language suffix. That way you can access them with the current page’s language code. For another user here, I slightly altered the plugin to do alternating text inputs and textareas. There’s a screenshot in another forum thread: link.
Wouldn’t it be more clever to create one plugin that does the whole job?
While it would be nice to have an in-built method, there are so many ways to build a multilingual site, you end up having to predetermine a structure. MLP had that kind of intention, but its size also made it harder to maintain.
The “duplicate article” feature would be needed to group articles of the same content in different languages / At the end this will be more of a solution for sites with a few languages (idealy 2) …
I agree, it gets more complex with multiple languages. You could still have a “clone” function on a per language basis but you only have the reciprocal fields for one pair. Probably this would need another linking concept for multiple language.
coupling of de+en sections via the same page template
…
I do not see such a problem here. At least for me personaly it is not a problem.
Depending on site structure, that can often be the case, I agree. But sometimes several sections of a site have the same structure and one only needs one page template for them all. It’s not a big problem with your method, just a requirement worth being aware of.
And I also do not have my page template in txp directly. I include them via php anyway to edit them in my editor.
Have you tried etc_flat? It replaces the old rah_flat/oui_flat/cnk_versioning plugins of the past and loads your theme templates from files (when in debugging mode). You can then work on them using your favourite text editor. It’s not perfect but pretty good.
… but like that I would be still able to use same page templates for different pages. Because the page template is different but the file that is included could still be the same
True, that enables you to source the same page template for multiple sections but under different names. Theoretically one could do this in Textpattern too by putting the structural page template (your master layouts so to speak) in a form and then using txp:output_form in the page template itself to assign them to the page templates for your section groups. (I’m not sure if there’s a way to call another page template from within a page template but maybe Oleg or Stef will reveal it shortly :-)
Anyway, nice ideas all round :-)
TXP Builders – finely-crafted code, design and txp
Offline
Re: Multi-Lingual Site
I checked out
jcr_section_custom
That would do it similar to how I did it before. But I thought I am using adi_menu anyways so why not build my language structure in there so that the system knows the curent language. It saves me one plugin. And it has the big advantge that adi_menu will display the sections with indent. So you can nicely see if something is an “en” or “de” section when working in the backend.
I am curious for the image captions now. Did you manage to get it working with the help of your unpublished plugin? Would you pass it over to me?
Thinking about it made me change the inclusion of my language snippets again.
I include them like this now:
<txp:output_form form='language_<txp:variable name="lang"/>'/>
Which is nicer of course. I will see if I can use this in other places.
I tried
<txp::language_<txp:variable name="lang"/>/>
somewhere along the way but it was not working. Grrrr …. didn´t think about trying it with the conventional syntax of output forms.
I would like to write a new summary of my approach once this is more simple and streamlined than it is now. Would be great if there are as less plugins and manual adjustments as possible.
So one last thing about the use of smd_query.
Maybe I will find a way around it but is it really a no go in terms of performance to have 1 or 2 more DB selects running in the back? And what if I would use jcr_section_custom to detect the sister section of my current section? Wouldn´t that also mean there is an extra select going on in the back?
Offline
Re: Multi-Lingual Site
I used jcr_image_custom to create additional image custom fields and named them with a _de or _en language suffix.
Great stuff. That answers my question above (which I wrote during your last post popped up)
I will go and grap it.
one plugin …
… to rule them all. You are right. It would get quite complicated. But for future websites I am building myself and for others it would be cool to have something like:
Install Plugin A, B and C use this 3 output forms + 5-10min of fiddeling around and you have setup textpattern to work with multilanguages (at least 2) in a solid way.
And thanks for the other ideas. I definitely will check it out.
Offline
Re: Multi-Lingual Site
demoncleaner wrote #329690:
Hehe, you write more quickly than I can type :-)
I am curious for the image captions now. Did you manage to get it working with the help of your unpublished plugin?
That was just using jcr_image_custom (see above and the linked thread for a screenshot).
I include them like this now:
<txp:output_form form='language_<txp:variable name="lang"/>'/>...
Yes, that’s what I meant with the lang_prefix as tag-in-tag. If you name your other fields e.g. your image custom fields, your language snippets (and parallel section custom fields if using them) to include the prefix, you can avoid all the if_this_language then show this else show that.
I tried
<txp::language_<txp:variable name="lang"/>/>...… but it was not working.
I don’t think you can construct an actual tag like that. If you make your shortcode accept an attribute, e.g. <txp::language lang='<txp:variable name="lang"/>' /> you can include variable as an attribute, but it’s then almost the same as the output_form tag above. Or you assume the default to be the current variable and your shortcode will always output the current page-language’s snippet form based on that with no attribute required.
So one last thing about the use of smd_query. Maybe I will find a way around it but is it really a no go in terms of performance to have 1 or 2 more DB selects running in the back?
No, it’s not a problem at all. Only if it gets out of hand and sometimes there’s no other way. If you are worried that your page has too many queries, you can also use a caching plugin to save the pre-rendered page output.
And what if I would use jcr_section_custom to detect the sister section of my current section? Wouldn´t that also mean there is an extra select going on in the back?
Yes, of course, with jcr_section_custom there’s also a database query. I don’t think the current txp:section tag gets all the fields and there’s not txp:section_info tag like there is for image_info.
TXP Builders – finely-crafted code, design and txp
Offline
Re: Multi-Lingual Site
I don’t think the current txp:section tag gets all the fields and there’s not txp:section_info tag like there is for image_info.
But there is one for the adi_menu.
adi_menu_info and adi_menu_if_info do quite a good job here.
Give me some days to improve the current setup.
Last edited by demoncleaner (2021-04-06 16:10:06)
Offline
Re: Multi-Lingual Site
Just a thought that popped up this morning …
I am pretty sure you guys have been there already but I wanna make sure.
What if we would call the sections like:
services_de services_en
Like that we would know already the current language through the sections names.
I am sure this is more or less what jakob was doing with the unpublished plugin.
That would also help in the backend chosing the correct section for an article. Because if you have sections called:
Leistungen Services
They won´t be listed up nicely underneath in a later state. And it won´t be easy to find the right sister-section.
Whereas
services_de services_en
would be.
Also the potential duplicate plugin could list the installed/needed languages and could ask you up front into which language you want to duplicate an article. Let´s say you have written an article for service_de and want to write the english version next, you would just have to click duplicate (selectbox to “en”) and it will put it to services_en. It then could also check if for this article(_id) in this language (section group e.g. “services”_xx) another article exist and only allow you to duplicate it if not.
I just definitely think that speaking urls is the only way.
So somehow www.domain.de/services_de/ would have to be rewritten to www.domain.de/leistungen/
Or what would be wonderful if adi_menu could get a feature in the backend (like the indent feature) that let´s you see “alternative titles” (idealy in combination with their parent sections) instead of titles. That would solve a lot! And you would have get the best for the urls and the handeling in the backend.
Meanwhile I managed to improve my first setup.
Now pages can be used as usual!
I also found a way to potentially get rid of the htaccess entry by using virtual sections in adi_menu but I did not follow this road any futher. Because having your languages as REAL “root” sections gives you the benefit on having the sections nicely displayed in the backend. That could be obsolete if adi_menu would be tweaked like described above.
Last edited by demoncleaner (2021-04-07 06:49:37)
Offline
Re: Multi-Lingual Site
Just for completeness:
Here is plugin (dem_clone) and a tutorial on how to setup adi_menu and deal with the multi-lingual approach.
Offline