This is a follow-up to #2651812: locales_source and i18n_string tables heavy write.

That fix made it so that i18n integration could be disabled, which is a huge relief from a performance stand-point. However, there's a good chance that you might want translation of some metatags, but not all. On a recent site I had about 800K rows in the locales_source table that were owned by metatag. Breaking them down by tag name, I got the following results:

mysql> select SUBSTRING_INDEX(location, ':', -1) as tagname, count(*) from locales_source where textgroup = 'metatag' group by tagname LIMIT 500;
+----------------+----------+
| tagname        | count(*) |
+----------------+----------+
| canonical      |   145254 |
| description    |    87297 |
| generator      |   125840 |
| image_src      |    72154 |
| keywords       |    81428 |
| modified_time  |     3522 |
| news_keywords  |        4 |
| published_time |     3522 |
| revisit-after  |        1 |
| robots         |        5 |
| shortlink      |   145247 |
| title          |   147370 |
| type           |       33 |
| updated_time   |     3524 |
| url            |        3 |
| username       |       30 |
+----------------+----------+
16 rows in set (4 min 38.08 sec)

Most of these tags do not need translation: canonical_url, generator, shortlink, modified_time, etc. I'd like to see an option for selectively enabling translation for only whitelisted tags. For starters I think the following should be translated but all others ignored:

- title
- description
- keywords

This would allow for the desired meta tags to continue to be translated while saving ~80% of the rows being generated in the locales_source table.

Comments

quicksketch created an issue. See original summary.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch as a volunteer and at Backdrop CMS, Lullabot commented
Related issues: +#2665914: Multilingual locales_source table textgroup metatag, +#2687309: Performance: I18n integration triggers a lot of db writes, +#2651812: locales_source and i18n_string tables heavy write
DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna at Mediacurrent commented
Title: Selectively use i18n_string for certain metatags » Allow control of which meta tags can be translated
Issue tags: +Usability

Hey there quicksketch :)

You are completely right. There are some meta tags that should always be translatable ("title" and "description" tags), some that never should be ("robots" tag) and a few that some sites might want to translate ("image" tags) depending on their needs. So lets expand the internal API to account for this.

The question is, what would be the best UX to provide for this? Define a option on meta tag definitions that lets them be grouped into "Never translate", "Optionally translate" (with a variable to toggle), "Always translate"? Provide a settings page full of checkboxes to control which meta tags can be translated (waits for people to start screaming)? Some combination of the three?

DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna at Mediacurrent commented

BTW, that query is great for analyzing a site's data, thanks :)

Here's what one (busy) site was showing:

+---------------------+----------+
| tagname             | count(*) |
+---------------------+----------+
| canonical           | 2        |
| description         | 7        |
| keywords            | 7        |
| lastmod             | 1        |
| title               | 8        |
| url                 | 2        |
+---------------------+----------+
Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid at Lullabot commented

I would say keep it simple and make it a translatable => TRUE/FALSE flag in hook_metatag_info(). You can expose options for enabling or disabling translations based on which ones are TRUE.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch as a volunteer and at Backdrop CMS, Lullabot commented

I would say keep it simple and make it a translatable => TRUE/FALSE flag in hook_metatag_info().

That sounds perfect. And then customizations if needed could be made with hook_metatag_info_alter(). No user settings needed at all IMO. The over-translation of tags isn't a problem until it becomes a Real Problem™. So having it be controlled by developers for starters and exposed through a UI later only if really needed seems like a good way to go.

DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna at Mediacurrent commented

We already have the 'image', 'url' and 'is_language' attribute, now we're talking of adding another. How about we follow the D8 branch and combine them into a 'type' attribute (#2692117: Add type metadata to tags) which indicates the type of data allowed, and then act accordingly?

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid at Lullabot commented

I still feel pretty strongly that a 'translatable' flag should be separate. There may be use cases where people want to have different values for non-text meta tags, and the API shouldn't need to limit them.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch as a volunteer and at Backdrop CMS, Lullabot commented

I read through #2692117: Add type metadata to tags but it wasn't actually clear to me what strings would be translatable, ("label", "string"?) or how you could determine what other various flags might make up a particular type of data. Maybe in D8 that is more clear if you can specify flags on the data types directly, but I don't think that patch actually uses the D8 Typed Data system. So currently a "type" is nothing but a string that might have arbitrary behavior attached to it.

I think exclusively using "type" makes sense if you can do something like this (which you could in D8 with actual data types, though this isn't real syntax):

if ($metatag->type()->isTranslatable()) {

But if we have to resort to something without a real type I wouldn't want to have to do this:

if (in_array($metatag->type, array('label', 'string', 'foo_type'))) {
// OR
if (in_array($metatag->type, metatag_translatable_type()) {
// OR
if (metatag_is_translatable($metatag)) {

I'm sure there are other ways of figuring it out, but the point is you'd have to have something that figures out the mapping between what the "type" is and what flags that type might have (is image, is translatable, is date, etc).

So for simplicity, without actual types, it may be easiest to just continue with putting the flags directly on the metatag types, which makes for a direct check.

if ($metatag->translatable) {

Although even with real typed data you'd probably run into situations where you need a flag that isn't already on the existing data types. In which case you'll probably end right back at putting the flags on the metatag type all over again.