Challenging upgrade and redesign issues 😳

Kjeld · 2021-02-09 14:47:33

Once again, thank you all for thinking with me on this one and for the suggestions. I really appreciate it.

If I understand all the suggestions correctly, they are for translations of the articles only and not the categories and the rest of the site?

jakob · 2021-02-09 14:48:53

Kjeld wrote #328673:

MLP inserts the language markers, but otherwise leaves the URLs alone, I believe.

My mini-plugin does the same. It strips off the first part of the url if it matches one of the permitted language codes and passes on the rest of the URL for Textpattern to handle as normal. If an incorrect language code is input it defaults to a standard lang code. There’s a tag to output the lang code.

I have already used up all my custom fields on this site… I guess I could use glz_custom_fields if it still works with the latest txp version

glz_custom_fields in the v2 still works on the latest txp version :-)

Kjeld · 2021-02-09 14:54:46

jakob wrote #328674:

I’m sure I can explain it better if you have more detailed questions. And it may not all be necessary depending on how you have your site setup and how much of MLP you were using.

Given your extensive image catalog and the need to keep article + image IDs intact, you may find that some careful manual offsite preparation of the images and the corresponding txp_image table may be much quicker than re-uploading and making things match. It feels a bit messy and requires working carefully and diligently, but it’s a one-off exercise and from then on you can add new images as required.

This is what the modified jcr_image_custom outputs:

Thank you, Jakob.

That screenshot of jcr_image_custom looks awesome. I hadn’t considered using it that way. Very smart set-up.

And that is a beautiful photo! I miss Italy…

Kjeld · 2021-02-09 15:02:41

jakob wrote #328676:

My mini-plugin does the same. It strips off the first part of the url if it matches one of the permitted language codes and passes on the rest of the URL for Textpattern to handle as normal. If an incorrect language code is input it defaults to a standard lang code. There’s a tag to output the lang code.

glz_custom_fields in the v2 still works on the latest txp version :-)

Thanks for the additional info, Jakob.

How do you manage the translations for the rest of the site, like the categories, general lay-out, alerts, etc.?

jakob · 2021-02-09 16:03:09

Kjeld wrote #328678:

How do you manage the translations for the rest of the site, like the categories, general lay-out, alerts, etc.?

The lang prefix plugin provides a tag that outputs en or ja (or whatever) depending on the language of the current page. It will use what’s in the url for that and fall back to a default if not supplied, but if you want to allow people to access articles without there being a language prefix code, you could also store the language code with each article in a custom field and then retrieve that if the url prefix is not available.

Once you have that, you can use it in your page template, e.g.

<txp:output_form form='<txp:jcr_page_langprefix />_header' />

which would output ja_header or en_header depending on the language of the current page.

For general text strings, smd_babel offers a way of adding custom strings. Here too you can name your strings mysite_en_welcome, mysite_ja_welcome, etc.

And then output:

<txp:text item='mysite_<txp:jcr_page_langprefix />_welcome' wraptag="h2" />

to get the respective output.

You can also store the language prefix in a variable …

<txp:variable name="language" value='<txp:jcr_page_langprefix />' />

… and test for it with if_variable, e.g.:

<txp:if_variable name="language" value="ja">
    My Japanese content block
<txp:else />
    My English content block
</txp:if_variable>

… like the categories

I’m not sure how you’re using these. If you have categories in the respective language that correspond to each other, you need a way to map them. It’s the same principle as for sections. e.g.

Variant 1 – A variable map of all sections/categories

Create a form in which you “explain” to TXP how your respective sections and categories link to each other across the languages, and load that high up on your page. It’s just a kind of list of from->to information.

<!-- section map -->
<txp:variable name="sec_landscape">landschaft</txp:variable>
<txp:variable name="sec_landschaft">landscape</txp:variable>
<!-- category map -->
<txp:variable name="cat_landscape">landschaft</txp:variable>
<txp:variable name="cat_landschaft">landscape</txp:variable>
…

And then to make a link to the corresponding other section or category in your page or form template, you’d do:

<!-- section link -->
<txp:section name='<txp:variable name=''sec_<txp:section />'' />' link title />

<!-- category link -->
<txp:category name='<txp:variable name=''cat_<txp:category />'' />' link title />

with double single quotes for the tag-in-tag-in-tag (I know 🙄). That should link to the respective other language section or category of the one you are currently on. So, if you are currently on the “landscape” section, the link would be to the “landschaft” section, and vice versa.

Variant 2 – Using jcr_section_custom

Instead of creating the “map” up front, you can describe the relationship between the sections with each section. With jcr_section, you can add up to five new custom fields for a section. You could create one called, for example partner_section, and then …

In the edit section pane for the “landscape” section, you’d put “landschaft” in that custom field, and in the edit section pane for the “landschaft” section, you’d put “landscape” in that custom field (i.e. always the respective other language).

Then, if you want to provide a language switch between sections, you’d just need:

<txp:section name='<txp:jcr_section_custom name="partner_section" />' title link />

The same principle would apply to categories … except … I haven’t made a jcr_category_custom plugin, at least not yet!!

—-

If, on the other hand, you have categorised your photos according to the same categories, but all you need is to show a different title for your category in the respective language, e.g. all your articles/images are assigned to the category name “landscape”, but you want to show “Landschaft” on a German page, then you could create a smd_babel string for that, e.g. de_cat_landscape = “Landschaft” and then output it with:

<txp:text item='de_cat_<txp:category />' />

or, if I were to make the jcr_category_custom plugin, then you could use a category custom field to store the German (or Japanese) title of the category alongside the regular category title. You’d reference your category as normal, but use the jcr_category_custom tag to output the title in the other language, e.g.:

<txp:category title /> | <txp:jcr_category_custom name="de_title" />

It really depends on your specific setup.

I can imagine that someone might able to come up with a tidier, less verbose way of looking up the respective other languages name/title but this one-to-one map works well enough.

etc · 2021-02-09 17:40:41

Kjeld wrote #328678:

How do you manage the translations for the … general lay-out, alerts, etc.?

It’s a shame there seems to be no way to define LANG and other constants otherwise than in config.php. An early bigbang callback, maybe?

Bloke · 2021-02-09 17:42:52

etc wrote #328685:

An early bigbang callback, maybe?

Yes!

EDIT: although plugins aren’t loaded at that point…?

Last edited by Bloke (2021-02-09 17:44:22)

etc · 2021-02-09 17:46:18

Bloke wrote #328686:

Yes!

EDIT: although plugins aren’t loaded at that point…?

Drat!

Kjeld · 2021-02-10 03:53:16

jakob wrote #328680:

The lang prefix plugin provides a tag that outputs en or ja (or whatever) depending on the language of the current page. It will use what’s in the url for that and fall back to a default if not supplied, but if you want to allow people to access articles without there being a language prefix code, you could also store the language code with each article in a custom field and then retrieve that if the url prefix is not available.

Once you have that, you can use it in your page template, e.g.

<txp:output_form form='<txp:jcr_page_langprefix />_header' />...

which would output ja_header or en_header depending on the language of the current page.

For general text strings, smd_babel offers a way of adding custom strings. Here too you can name your strings mysite_en_welcome, mysite_ja_welcome, etc.

And then output:

<txp:text item='mysite_<txp:jcr_page_langprefix />_welcome' wraptag="h2" />...

to get the respective output.

You can also store the language prefix in a variable …

<txp:variable name="language" value='<txp:jcr_page_langprefix />' />...

… and test for it with if_variable, e.g.:

<txp:if_variable name="language" value="ja">...

I’m not sure how you’re using these. If you have categories in the respective language that correspond to each other, you need a way to map them. It’s the same principle as for sections. e.g.

Variant 1 – A variable map of all sections/categories

Create a form in which you “explain” to TXP how your respective sections and categories link to each other across the languages, and load that high up on your page. It’s just a kind of list of from->to information.

...

And then to make a link to the corresponding other section or category in your page or form template, you’d do:

...

with double single quotes for the tag-in-tag-in-tag (I know 🙄). That should link to the respective other language section or category of the one you are currently on. So, if you are currently on the “landscape” section, the link would be to the “landschaft” section, and vice versa.

Variant 2 – Using jcr_section_custom

Instead of creating the “map” up front, you can describe the relationship between the sections with each section. With jcr_section, you can add up to five new custom fields for a section. You could create one called, for example partner_section, and then …

In the edit section pane for the “landscape” section, you’d put “landschaft” in that custom field, and in the edit section pane for the “landschaft” section, you’d put “landscape” in that custom field (i.e. always the respective other language).

Then, if you want to provide a language switch between sections, you’d just need:

<txp:section name='<txp:jcr_section_custom name="partner_section" />' title link />...

The same principle would apply to categories … except … I haven’t made a jcr_category_custom plugin, at least not yet!!

—-

If, on the other hand, you have categorised your photos according to the same categories, but all you need is to show a different title for your category in the respective language, e.g. all your articles/images are assigned to the category name “landscape”, but you want to show “Landschaft” on a German page, then you could create a smd_babel string for that, e.g. de_cat_landscape = “Landschaft” and then output it with:

<txp:text item='de_cat_<txp:category />' />...

or, if I were to make the jcr_category_custom plugin, then you could use a category custom field to store the German (or Japanese) title of the category alongside the regular category title. You’d reference your category as normal, but use the jcr_category_custom tag to output the title in the other language, e.g.:

<txp:category title /> | <txp:jcr_category_custom name="de_title" />...

It really depends on your specific setup.

I can imagine that someone might able to come up with a tidier, less verbose way of looking up the respective other languages name/title but this one-to-one map works well enough.

Thank you very much for all the additional information, Jakob.

Your plugins seem to offer far more potential functionality than I imagined. I will have to take some time to study your advice more carefully. The best is probably to fiddle with your plugins on a dev site.

Is there a multilingual site that you have developed based on this advice that I may have a look at?

jakob · 2021-02-10 09:04:28

Kjeld wrote #328691:

Is there a multilingual site that you have developed based on this advice that I may have a look at?

I’d have to ask as the site was not one of my own. I had a test account but it no longer has admin rights so one can’t see the principle. I guess that would only work through screen sharing pending permission.

The best is probably to fiddle with your plugins on a dev site.

This may be simplest: a general structural setup that echoes want you want to have and some basic test content to test practical implementation without doing open-heart surgery on your actual site. Feel free to email me off-forum if you like.

Kjeld · 2021-02-10 09:25:06

jakob wrote #328694:

I’d have to ask as the site was not one of my own. I had a test account but it no longer has admin rights so one can’t see the principle. I guess that would only work through screen sharing pending permission.

I don’t require admin access. I would just like to have a look at the lay-out for general understanding, and the page source to see how the multilingual implementation looks to search engines.

This may be simplest: a general structural setup that echoes want you want to have and some basic test content to test practical implementation without doing open-heart surgery on your actual site. Feel free to email me off-forum if you like.

That is very kind of you, Jakob. Thank you!

johnstephens · 2021-05-25 21:12:03

jakob wrote #328666:

Interesting! Recently, I’ve been helping quite a few people upgrade from 4.6.2 upwards and for the most part it works quite well depending on the plugins.

1. Replacing MLP: I helped out someone recently with a mini language-prefix url scheme plugin so that they could do /en/… and /de/… and then the rest of the url would be handled as normal. The en or de part is separated out into a variable that can then be output or if_queried on the page.

That’s only part of the puzzle. For sections, you can either set up a set of variables to map en->ja and ja->en matching sections, or you can use a plugin like my jcr_section_custom to store the respective “partner section” with each section in the section edit pane. The site author used a similar principle for articles: a custom field holding the article_id of the respective “partner article” and a custom field denoting the current article’s lang code.

For fixed strings the site author used smd_babel, prefixing the string names with the respective lang code, e.g. en_mystring and ja_mystring.

We also used a modified version of jcr_image_custom to store the caption and alt-tag (or copyright) with each image. Again, those were named by prefixing with the lang code. You can then design your page templates using the lang code variable as a tag-in-tag to output in the respective language. It’s not perfect and depends very much on your site setup, but it worked.

I’m in a very similar boat: I have an older site that uses MLP along with glz_custom_fields on Textpattern version 4.6.2, and we have to upgrade because it no longer works with the server’s version of PHP. I’m seeking the most painless path possible, but it doesn’t look promising.

Reading over the recommendations here, Jakob yours sounds most comprehensible as a potential upgrade path. What I don’t quite follow is what the exact practical steps would be.

Here’s what I’m guessing:

Backup data and file system.
Deactivate and delete the MLP plugin.
Follow Textpattern’s upgrade instructions for version 4.8.5 stable. This will replace the file hacked by MLP.
- (It would be great to know about any particular gotchas or known perils of going from 4.6.2 -> 4.8.5.)
Set up a mini language-prefix url scheme plugin to handle URL language codes.
- How?
- Alternatively, it might be feasible to use adi_gps and parse the URL with a .htaccess ReWrite rule to point language-tagged URLs to ?language=en-style query strings?
Create two new custom fields: Language and paired artilce_id, and (somehow) tag all the articles with this information.
- Could this be automated using some MySQL query on the existing Textpattern and MLP tables?
Set up smd_babel.
1. Migrate all of the existing MLP language strings.
  - Could this be automated using some MySQL query too?
2. Edit all the site templates to use smd_babel strings instead of MLP.
Edit all the site templates to use the URL scheme plugin (or adi_gps) to show the right article depending on selected language.
- I’m a little hazy about this, but I think I can peer a solution through the fog. Any guidance about this would be appreciated.

Is this somewhere in the neighborhood of what you have done, Jakob? Can anyone point out errors in my thinking or clear up any of the points where I am obviously confused?

Thank you in advance!

Textpattern CMS

Textpattern CMS support forum

#13 2021-02-09 14:47:33

Re: Challenging upgrade and redesign issues 😳

#14 2021-02-09 14:48:53

Re: Challenging upgrade and redesign issues 😳

Kjeld wrote #328673:

#15 2021-02-09 14:54:46

Re: Challenging upgrade and redesign issues 😳

jakob wrote #328674:

#16 2021-02-09 15:02:41

Re: Challenging upgrade and redesign issues 😳

jakob wrote #328676:

#17 2021-02-09 16:03:09

Re: Challenging upgrade and redesign issues 😳

Kjeld wrote #328678:

#18 2021-02-09 17:40:41

Re: Challenging upgrade and redesign issues 😳

Kjeld wrote #328678:

#19 2021-02-09 17:42:52

Re: Challenging upgrade and redesign issues 😳

etc wrote #328685:

#20 2021-02-09 17:46:18

Re: Challenging upgrade and redesign issues 😳

Bloke wrote #328686:

#21 2021-02-10 03:53:16

Re: Challenging upgrade and redesign issues 😳

jakob wrote #328680:

#22 2021-02-10 09:04:28

Re: Challenging upgrade and redesign issues 😳

Kjeld wrote #328691:

#23 2021-02-10 09:25:06

Re: Challenging upgrade and redesign issues 😳

jakob wrote #328694:

#24 2021-05-25 21:12:03

Re: Challenging upgrade and redesign issues 😳

jakob wrote #328666:

Board footer