UI for locale string versions

Let me add a minor correction to the info about VERSION column: locale() function will select any matching string regardless the VERSION, and then record the current version back to the table (i.e. update version) if it differs. (Or so it does in 6.x, I hope 7.x didn't change that.) So in fact all the strings are potentially in use, and the VERSION column holds the Drupal version of last usage for each string, making it possible to identify obsolete strings. This is also used for locale caching (or pre-loading if someone understands this term better), where only strings active (already) in current version are cached (pre-loaded).

The strings with old versions in table are long unused, usually strings from previous versions of Drupal that got changed in a later version you upgraded to - these are candidates for removal, and also probably the cause of seemingly duplicate strings in locale search - mostly one is capitalized, other not, third have a typo fixed somewhere, so they look similar but are technically different strings - there shouldn't be any copies of the same string. I agree that it's difficult to pick the right one for edits in such cases, and version info might help here.

In the other hand, these strings are not obsolete for sure. They may be just strings belonging to a page you didn't visit since the upgrade, but you might still be going to - after enabling more features in a module, or hitting some rare error condition.

Just re-stating the info, as I wasn't sure how much the initial post is clear to everyone.

As for the patch, I can only briefly look on it, no chance to apply and test now. It seems to be more or less what I proposed on the other issue (part of), and I don't see any problem with it - but as I said, it's just a brief look.

Before/after patch screenshots would help a lot here.

This will need to go into 8.x first, and would likely need to be a Drupal 7 contrib module since it's a UI change.

Also can this be merged with #175798: UI for pruning dead locale strings or is it really a different patch?

This issue has existed since Locale module was included in core (afaik). Bumping up to "major" or "critical" now prevents development of other features in Drupal core (see #1050616: Figure out backport workflow from Drupal 8 to Drupal 7), so I'm now re-categorizing issues that should not prevent development of core. Note that since this is not an API change, there's still a good chance of fixing this in 8.x and getting it back-ported into 7.x.

As JirkaRybka explained, the VERSION info is only ever used to speed up the locale cache. That is the only role of it. Still in Drupal 7 if you look at it: http://api.drupal.org/api/drupal/modules--locale--locale.module/function... It will in effect slow down the locale system a bit on new sites, but as it picks up the strings for the current version, it will speed up and set at a standard level. Because this is only really used internally for a very specific reason and does not affect lookups in general, I'm not sure that we even need to expose this information and confuse users with it, should we?

As of 6.x (I'm not up-to date on 7.x and further), the problem is/was, that the UI for translation of strings often shows several nearly identical ones in search results (coming from different versions previously used on the site, given that we don't have effective pruning, differing only in minor stuff like capitalization, t() placeholders, typo-fixes etc.), so if one needs a slight adjustment of a translation, it takes several trial-and-error iterations to find the exact entry that's really in use (even worse if caches need to be flushed along the way). VERSION info might help with that, in this way or another.

• Gábor's post in #5 indicates that it's not clear that we should add this to the UI.
• In order to evaluate the proposed change, let's get before-and-after screenshots.
• The D7 patch will likely need to be rerolled and forward-ported to D8 before we create the screenshots.

Thanks!

Rerolled the patch for 7.x HEAD. Probably needs manual review for 8.x because the following line does not exist in 8:

$sql_query->fields('s', array('source', 'location', 'context', 'lid', 'textgroup'));

Tagging for backport as well.

Uploading a new patch because I missed the change in the locale.css file.

Here are before/after screenshots for this patch

I looked into forward-porting this to D8, but the UI and surrounding code changed quite a bit in #1452188: New UI for string translation (which went in almost a year after Gábor's comment in #5).

I think this definitely needs to be re-evaluated. Personally I'm on the side of not including this information in the UI. Is there a better way of solving this problem?

tagging for updating issue summary. reading contributor task doc on making good issue summaries: http://drupal.org/node/1427826

Tagging

ui_locale_string_version.patch queued for re-testing.

adding tag for drupal 8 multilingual, but I dont think it is a priority right now, given where we are in the release cycle.

I still contest that multiple identical strings exist in the database with only the version being different. The version number is not used to duplicate strings per different versions but to keep track of which version each string was used in last (where "used" means gone through a runtime t() at some point). It is not used to multiply source/translation strings. Why would that be useful? JirkaRybka already explained this in #1. Duplicate *looking* translation strings may come from all kinds of sources:

• Near identical strings as explained by JirkaRybka in #6, which may have typos, whitespace, etc. fixed. This applies to all versions of Drupal.
• Strings that are identical but have different context applied to them. This applies to Drupal 7 and 8. The context is actually displayed in the search results.
• Strings that are identical but used in different textgroups. This applies to Drupal 7 only. You can filter to textgroups on the UI. Strings that appear in menus may be differently translated for the identical source strings compared to the same string appearing as a block title.

I don't believe the version tracking may result in duplicate strings, if so, please show how it happens on your website as well as if you happen to find the code where it is duplicated for the new version, please don't hesitate to cite that.

No feedback from reporter. See #18.