Add string context and location filters to the translate interface

Hey, this is a very helpful filter. In fact, it's more essential than any of the existing filters. However, it would be great if, instead of a free text field, the filter was another dropdown with the full list of contexts. The trouble with a free text field is that the content manager doesn't know the context names. Even if the list is long, it would still be more useful for the content manager to have a list of names to pick from.

Regardless, thanks for this very helpful patch!

I too have used the approach of prefixing all site specific contexts with a unique keyword and it does work well.

Thanks for the reply!

This is very useful. Thanks.

Regarding the usage of a textfield vs a dropdown I think both are very needed and the perfect solution would be to provide both in the interface. If the user wants to choose a context from the dropdown, it's easily there and usable. If they fill the textfield then that will be used.

I know this is harder to implement but maybe we can help if there's interest in pushing this into core.

Thanks again.

I used this patch and it works great! I think it needs review and hopefully a commit :)

Has anyone created a patch that creates the same filter on the Translate Export?

This patch works like a charm, thanks
This should really be committed in next release as it fits a widespread need.

works great. Commit please.

Great patch. I also find Location a helpful field to search on. Here's a patch with that field added.

I guess automated testing doesn't work unless you create the patch against an actual branch.

Patch applied cleanly and works perfectly. Code appears to confirm to the coding standards. Looks great - such a useful addition!

Do we need to add some automated tests before we can get this committed?

We are currently developing a D8 Site for which this same feature would be very useful. Here is the feature request for D8.

Nice patch, i created one looks like this, but the context filter is the select options, because context is used in code,then sometimes is difficult to remember the names that you used.

What do you think?

jweowu: sorry.

Maybe, one autocomplete works well?

Look this patch. What do you think?

Based on the above discussion it looks like this is relevant for Drupal 8 too and would need to go in there first.

Also retitling based on the direction of the latest patches (although perhaps they could be separate issues instead).

Will the average site administrator really have a clue what "location" and "context" mean in this user interface?

working on this

A location filter in Drupal 8 could allow to filter to configuration strings, or JS strings, that kind of stuff. A context filter could filter down to long month names or PHP date formats, etc. I think with concrete options provided the users could easily figure it out (eg. for context, the filter can be a dropdown in Drupal 8, for location TYPE the list can be a dropdown).

So the problem is that I'd need a method on StringStorageInterface, something like getDistinctContexts() but that isn't possible to add in patch, or even minor.

Catch suggested adding a public method to StringDatabaseStorage() which is a possibility, but not very neat. So the cleanest option seems to be adding a new interface in 8.1.x then ?

pasted log from IRC

<swentel> alexpott, we can't add methods to an interface in a patch release I guess ?
<alexpott> swentel: nope
<catch> swentel: don't think we can do that in a minor either, would need to be a new interface and update StringDatabaseStorage
<swentel> catch, seems like it yeah
<catch> swentel: in a patch we could possibly add a new @internal public method to StringDatabaseStorage
<catch> swentel: if it was to solve something horrible that can't wait until April.
<swentel> catch, it's a feature, nothing horrible

Regarding #22: makes sense - I actually hadn't read the complete thread, sorry about that. One downside of a textfield is that users would have to know which contexts exists in the first place (however, I quickly checked and the filters already use LIKE, so it could do partial matching). The immediate plus of a textfield is also that it allows us to implement this without having to make any changes to the class interfaces and even include this in a patch release.

Autocomplete would be nice indeed, but that requires updates to the interfaces which would only be possible for 8.1.

@Gábor Hojtsy any preferences ?

Patch which uses a textfield for the widget, it actually works nicely.

@jweowu: what is your use case for partial contexts in Drupal 8? Drupal 8 does not have textgroups and does not identify webform or content type translations with contexts. I don't think its a problem that we use a dropdown.

@jweowu: only shipped English strings are translated with locale now. What would modules use arbitrary translation contexts for then?

I can see how the textfield is useful in Drupal 7, although it is far from discoverable. I don't see the benefits of a textfield over a select box in Drupal 8 honestly. How do people know what to put there?

@jweowu: I see you are advocating to add a cumbersome UI element, so we don't need to add something less than ideal on the API. I would value a better UI over a very elegant API.

I agree with #31 that a text field isn't particularly intuitive as a filter since many wouldn't know what to put there but a select list would be nice.

Downgrading to 7.x to include a new patch in the next comment.

Since there are probably a handful of folks like myself that are still supporting 7.x sites, I'm including a new patch which is essentially just an update of #17 by @ljcarnieri to be compatible with the latest 7.x branch (and applies cleanly to 7.53).

I understand that there was still some discussion about the best way to implement this in 8.x, but since I haven't migrated to that version yet, I can't provide any useful in that direction. However, the code added by @ljcarnieri in this patch has turned the Context field into an autocomplete field which seems to address the big question of "Does the average user know what location/context are." Perhaps others might agree that this approach is sufficient to move this issue forward in 8.x?

Bumping back to 8.x

@hargobind - Thanks. I'm using the patch for 7.x so will be back to test. Do you maybe need to wait for the testbot before you switch back to 8.x? I have no idea.

Unrelated, but it's a bit more than a handful. :) https://www.drupal.org/project/usage/drupal

@othermachines - Yeah, I don't have much experience with the testbot, but it looks like the tests ran correctly against 7.x since that's what appears next to the test results, and even shows it on the test page for "DCI_CoreBranch". The failures don't seem to have anything to do with my code.

I appreciate you linking to the usage page, I haven't looked at it in a long time. Those stats make me feel better that I haven't yet had the time to adopt 8.x ;-)

Tested re-rolled D7 patch in #39 on a clean 7.53 installation and it applies cleanly and works as advertised. The autocomplete is a nice bonus. :) I've been hooking into the form to provide context "suggestions" in the field description, which is ugly and messy.

Be nice if we could get some work done on this for D8. (I'd offer, but I still have much to learn.)

Thanks, @hargobind.

Reroll of the patch from #46 against 8.4.x

Seems to work, but should the OR operator be changed to AND? If I search for next and give a context, it doesn't really help me to find the string "next" in certain context.

I agree with @mErilainen, it should use an AND condition and not the default OR condition.
I updated the patch to reflect this change.

Thanks for the patch. An interdiff file would be nice :) I noticed a minor thing:

+++ b/core/modules/locale/src/StringDatabaseStorage.php
@@ -427,6 +427,13 @@ protected function dbStringSelect(array $conditions, array $options = []) {
+    if(isset($options['filters']['context'])) {

Needs space after "if".

added space after "if" and interdiff before #46 and current one

The code appears to be ok but this needs testing. I'll see if I can do that soon.

The context search is working with and without the string text. There was still discussion about using a select list instead of a text field though.

This seems to satisfy "context". However, the idea of "location" was added to the discussion in #10 and #18. Can someone add that to the 8.x patch?

Updated patch to choose context from a select list instead of a text field.

Patch for select list updated with contexts sort alphabetically.

An other one for the version with textfield, to avoid "Illegal mix of collations" when searching with accents in the context textfield. The context column in DB being in "varchar_ascii".

Could someone add a Location search to these patches? It doesn't seem like that would be too much work.

Maybe my post in #3104585: Add context filtering capabilities to the core translation interface is a duplicate of this issue, so I ask my questions here:

1. Does this issue also covers a "context" filter for the translation export (.po file generation)? In my opinion this would be a very important feature for multilingual websites with custom modules that use "context" for their translation strings.
2. Does this issue contains a "context" column in the translations backend overview (as you can see on the screenshot image of the contrib module https://www.drupal.org/project/locale_translation_context)? I think that this column is helpful to quickly find a context Name.

As far as I can see the contrib module https://www.drupal.org/project/locale_translation_context offers a working solution (that suffers on too much core code duplication) and that is why this should be a core feature (but the working code is available in the contrib module)… Am I wrong? Where is help needed?

Thank you all for the previous work!

Here is the updated patch and interdiff against #60 since our client perfers the "Context" filter as a dropdown menu.

I made the following updates:

• Introduced a new interface to get all available contexts as per #21
• Alphabetical sort as per #60
• Rewrote the original query in #12. It includes a fix for context strings that are part of another context strings.
• Fixed deprecated code.

Here is Drupal 8.9.x-friendly patch that fixes condition object initialization.

As per #52, the default condition should be AND.

Rerolled. This applies cleanly against 9.2.x and 9.3.x.

Rerolled. This applies cleanly against 9.4.x.

@AndreRB: I didn't tested your patch #74, but I reviewed the code and it looks promising. Thank you for your work. Maybe someone else can test the patch to move status to RTBC...

#74 is fine for me to !

Re-rolled #74 on 10.0.x

Readding the D7 patch that was hidden by @Lekstat

@Lekstat why did you hide your own patch in #79?

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

The issue summary could be updated to show what the proposed solution is? Remaing tasks, etc.

Also will need test coverage to ensure it doesn't break.

I had some issues in #74 on the project for which I'm working on. The code section where all the available string translation contexts are fetched in the function translateFilters() didn't apply.

This is an updated version of the patch where the said code segment is placed between the filters array and language fetching sans English.

#83 seems to have some linting errors, please adjust those so that the tests can pass :)

FILE: /var/www/html/core/modules/locale/src/StringContextInterface.php
----------------------------------------------------------------------
FOUND 2 ERRORS AFFECTING 2 LINES
----------------------------------------------------------------------
9 | ERROR | [x] Opening brace should be on the same line as the
| | declaration
16 | ERROR | [x] Expected 1 blank line before function; 0 found

All right, as stated in #84, these should be fixed with the version provided in this comment, #85.

@jheinon_finland Drupal core issues are fixed in development versions. So please don't move versions down.
Current development versions is 10.1.x. Maybe the patch can be applied to previous versions and back-ported if needed but that's up to the core maintainers.

Can you upload a diff in the same comment? So people can see what you changed?

Issue summary still needs updating.

Tests are still needed.

And yes interdiffs need to be uploaded for #83 and #85

In this, I will upload the interdiff between versions #83 and #85. To answer #86, it appears it's not possible to edit an old comment and provide a file with it, so I will be uploading the interdiff file in this comment.

per #87

Updated MR to support Drupal 10, unfortunately couldn't rebase

Rebased MR 4174.

Is there any patch for 10.2.1 ?
Thanks

+1 This would be sooo useful, using this patch in many projects.

Rebased 4174 with current 11.x so it is mergeable again, but somehow messed up, the changes are correct but it shouldn´t show the ~1800 commits ... i´ll fix this now

Added a little context-filter testing to testStringSearch of LocaleTranslationUiTest

Still not sure if i messed up the MR, but it says 2 commits will be added when merged into 11.x so i think its principally correct, i´ll leave it like this for now

In my project, we had a Drupal 10.3 installation pointing to the patch of the MR, but with the rebase of the MR, the MR is not applicable anymore in Drupal 10.3.

So for those looking for a patch that work with Drupal 10.3, I'm attaching one to the issue.

Issue summary still appears to need to be updated.

also MR is showing 1000s

Also worth checking if this could be consolidated into #1853534: Reintroduce Views integration for locale.module since it makes integration a whole lot easier.

This will even more relevant when #3493070: SDC `enum` props should have translatable labels: use `meta:enum` is supported, as the context strings usage will likely increment a lot once SDC components can be translated.

Using patch from #105, works as expected on:

Drupal Core 11.1.7
PHP v8.3

Idk what happened, but the MR had more than 1900 commits and 1000+ changes 🙈
For now I fixed the branch against 11.x while keeping the original 5 pending commits as they were.

For the summary update.

Updated the issue summary.
Keeping the status in "Needs work" since it seems that the MR doesn't yet include the "filter by location" functionality.

I added the location filter solution proposed in earlier comments, though idk how I feel about the large amount of select options it can have, and the size of the filter.

Appears to need a rebase. Also the API change will need a change record please.

Rebased with latest code in main branch.
Added draft change record.

Hi @smustgrave, anything else needed?

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.