Currently we can filter by string, but not by context.
With a context filter you can easily list, for example, all translatable strings in the "Node types" group for some node bundle (e.g. page) by using the "type:page:" context filter.
The use-case which actually prompted this was using the webform localization contrib module, which incorporates the webform node ID into the context of each translatable string. It's really useful to be able to list strings for a specific webform, and omit the others, as things get really crowded really quickly.
Comment | File | Size | Author |
---|---|---|---|
#88 | interdiff_83-85.txt | 3.16 KB | jheinon_finland |
#39 | drupal-translate_string_context_filter-2123543-39.patch | 4.57 KB | hargobind |
Issue fork drupal-2123543
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #1
jweowu CreditAttribution: jweowu commentedComment #2
RogerRogers CreditAttribution: RogerRogers commentedHey, 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!
Comment #3
jweowu CreditAttribution: jweowu commentedIt needs to be a text field, because it's not necessarily a complete value you're searching for.
Certainly my use case was to find ALL contexts associated with a particular webform, by searching for the common prefix (and ditto for the example I gave in the issue description, whereby filtering on "type:page:" will find all string translation contexts for the 'page' node type.
I can see the potential use in also having a select list filter (although that list really can get huge), but the current approach has more general utility.
Comment #4
RogerRogers CreditAttribution: RogerRogers commentedI too have used the approach of prefixing all site specific contexts with a unique keyword and it does work well.
Thanks for the reply!
Comment #5
mario.awad CreditAttribution: mario.awad commentedThis 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.
Comment #6
daulet2030 CreditAttribution: daulet2030 commentedI used this patch and it works great! I think it needs review and hopefully a commit :)
Comment #7
jasonyarringtonHas anyone created a patch that creates the same filter on the Translate Export?
Comment #8
ericdsd CreditAttribution: ericdsd commentedThis patch works like a charm, thanks
This should really be committed in next release as it fits a widespread need.
Comment #9
stefanweberworks great. Commit please.
Comment #10
hargobindGreat patch. I also find Location a helpful field to search on. Here's a patch with that field added.
Comment #12
hargobindI guess automated testing doesn't work unless you create the patch against an actual branch.
Comment #13
nicrodgersPatch 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?
Comment #14
bird-cage CreditAttribution: bird-cage commentedWe are currently developing a D8 Site for which this same feature would be very useful. Here is the feature request for D8.
Comment #15
ljcarnieri CreditAttribution: ljcarnieri at CI&T for CI&T commentedNice 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?
Comment #16
jweowu CreditAttribution: jweowu commentedljcarnieri: Please see comment #2 and comment #3 above.
Comment #17
ljcarnieri CreditAttribution: ljcarnieri at CI&T for CI&T commentedjweowu: sorry.
Maybe, one autocomplete works well?
Look this patch. What do you think?
Comment #18
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedBased 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?
Comment #19
swentel CreditAttribution: swentel commentedworking on this
Comment #20
Gábor HojtsyA 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).
Comment #21
swentel CreditAttribution: swentel commentedSo 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
Comment #22
jweowu CreditAttribution: jweowu commentedI'm not familiar with D8 but, regarding the use of drop-down lists for this, does comment #3 not still hold?
Not including the ability to filter on a partial context value would be contrary to my original intent.
If the widget facilitates both a pre-populated drop-list and an arbitrary textfield input, that could be nice. I haven't spent much time thinking about the best approach to including a select list, but if D8 uses something like https://harvesthq.github.io/chosen/ to make excessively-long select lists manageable, I could see that working reasonably well. Failing that, I'd guess some kind of auto-complete widget might be appropriate?
In fact, an auto-complete field which also allowed you to submit incomplete text might be a nice way to combine the two requirements? That way you could see which contexts you were matching, and either select a specific one, or submit as-is to match all of them.
(edit: which might be what ljcarnieri's comment #17 provides? I haven't tried that patch...)
Comment #23
swentel CreditAttribution: swentel commentedRegarding #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 ?
Comment #24
swentel CreditAttribution: swentel commentedPatch which uses a textfield for the widget, it actually works nicely.
Comment #25
jweowu CreditAttribution: jweowu commented+1 from me for implementing this approach for 8.0.x and perhaps aiming to enhance it with autocomplete abilities in 8.1.
Comment #26
Gábor Hojtsy@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.
Comment #27
jweowu CreditAttribution: jweowu commentedI'm using Drupal 7, so I have no specific use case for this in Drupal 8 at present; but is it not still possible for contrib/custom code to create arbitrary translation contexts in Drupal 8?
Comment #28
Gábor Hojtsy@jweowu: only shipped English strings are translated with locale now. What would modules use arbitrary translation contexts for then?
Comment #29
jweowu CreditAttribution: jweowu commentedI'm not certain I understand the changes, but if modules cannot dynamically generate contexts which are visible to this interface, that probably does eliminate the need for partial matching.
Maybe that doesn't change things in practice, though? A select-based approach evidentially isn't possible to add earlier than 8.1, so I would still suggest that a textfield-based solution will be an improvement for the 8.0.x series, as it still provides the missing functionality, even if the interface might be improved later on.
Continuing to use LIKE matching for the textfield version would probably still be a convenience for the end user, even if it's no longer a necessity to facilitate partial matches.
Comment #30
jweowu CreditAttribution: jweowu commentedFurthermore, with a 8.0.x commit, we can hopefully make the backport to 7.x in short order, as the 8.1-specific UI enhancements would be a separate issue. That would be a nice bonus.
Comment #31
Gábor HojtsyI 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?
Comment #32
jweowu CreditAttribution: jweowu commentedThe benefit of a textfield for this is that it can be implemented in Drupal 8.0, whereas a select list cannot (at least not in a reasonable way).
The options appear to be:
a) Implement as a textfield for 8.0; backport to 7.x; enhance with select list in 8.1.
b) 8.0 gets nothing; implement as a select list for 8.1; "backport" the textfield approach to 7.x.
I think (a) seems better than (b).
I can see the context named in the results shown in the screenshot in #24, so that seems like an obvious way for everyone. Other people will already know what they're looking for. I don't think the fact that some people won't know what to do with it should prevent the addition of a feature which other people will know what to do with, and which may prove very convenient to them?
Comment #33
Gábor Hojtsy@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.
Comment #34
jweowu CreditAttribution: jweowu commentedSure. I had thought the consensus was the necessary API change for 8.0 was untenable, but I don't have an opinion on it myself. If the select list UI is still an option for 8.0 then I have no issue with that.
Comment #35
Kristen PolI 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.
Comment #38
hargobindDowngrading to 7.x to include a new patch in the next comment.
Comment #39
hargobindSince 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?
Comment #40
hargobindBumping back to 8.x
Comment #42
othermachines CreditAttribution: othermachines commented@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
Comment #43
hargobind@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 ;-)
Comment #44
othermachines CreditAttribution: othermachines commentedTested 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.
Comment #46
reekris CreditAttribution: reekris commentedReroll of the patch from #46 against 8.4.x
Comment #47
reekris CreditAttribution: reekris commentedComment #49
mErilainen CreditAttribution: mErilainen at Wunder commentedSeems 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.
Comment #52
jeroenbegyn CreditAttribution: jeroenbegyn at corecrew commentedI agree with @mErilainen, it should use an AND condition and not the default OR condition.
I updated the patch to reflect this change.
Comment #53
Kristen PolThanks for the patch. An interdiff file would be nice :) I noticed a minor thing:
Needs space after "if".
Comment #54
kostyashupenkoComment #55
kostyashupenkoadded space after "if" and interdiff before #46 and current one
Comment #56
Kristen PolThe code appears to be ok but this needs testing. I'll see if I can do that soon.
Comment #57
Kristen PolThe 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.
Comment #58
hargobindThis 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?
Comment #59
armandaslt CreditAttribution: armandaslt commentedUpdated patch to choose context from a select list instead of a text field.
Comment #60
raphaeltbm CreditAttribution: raphaeltbm commentedPatch for select list updated with contexts sort alphabetically.
Comment #61
nicrodgersComment #62
raphaeltbm CreditAttribution: raphaeltbm commentedAn 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".
Comment #63
hargobindCould someone add a Location search to these patches? It doesn't seem like that would be too much work.
Comment #64
M_Z CreditAttribution: M_Z commentedMaybe 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?
Comment #67
mbovan CreditAttribution: mbovan at MD Systems GmbH for Liip commentedThank 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:
Comment #68
mbovan CreditAttribution: mbovan at MD Systems GmbH for Liip commentedHere is Drupal 8.9.x-friendly patch that fixes condition object initialization.
Comment #69
mbovan CreditAttribution: mbovan at MD Systems GmbH for Liip commentedAs per #52, the default condition should be
AND
.Comment #71
DamienMcKennaRerolled. This applies cleanly against 9.2.x and 9.3.x.
Comment #74
AndreRB CreditAttribution: AndreRB at undpaul commentedRerolled. This applies cleanly against 9.4.x.
Comment #77
M_Z CreditAttribution: M_Z commented@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...
Comment #78
Kgaut CreditAttribution: Kgaut commented#74 is fine for me to !
Comment #79
Leksat CreditAttribution: Leksat at Amazee Labs commentedRe-rolled #74 on 10.0.x
Comment #80
Leksat CreditAttribution: Leksat at Amazee Labs commentedComment #81
hargobindReadding the D7 patch that was hidden by @Lekstat
@Lekstat why did you hide your own patch in #79?
Comment #82
smustgrave CreditAttribution: smustgrave at Mobomo commentedThis 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.
Comment #83
jheinon_finland CreditAttribution: jheinon_finland as a volunteer and at Wunder commentedI 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.Comment #84
Phonoman CreditAttribution: Phonoman commented#83 seems to have some linting errors, please adjust those so that the tests can pass :)
Comment #85
jheinon_finland CreditAttribution: jheinon_finland as a volunteer and at Wunder commentedAll right, as stated in #84, these should be fixed with the version provided in this comment, #85.
Comment #86
Martijn de Wit@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?
Comment #87
smustgrave CreditAttribution: smustgrave at Mobomo commentedIssue summary still needs updating.
Tests are still needed.
And yes interdiffs need to be uploaded for #83 and #85
Comment #88
jheinon_finland CreditAttribution: jheinon_finland as a volunteer and at Wunder commentedIn 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.Comment #89
smustgrave CreditAttribution: smustgrave at Mobomo commentedper #87
Comment #97
parisekUpdated MR to support Drupal 10, unfortunately couldn't rebase
Comment #99
bbu23 CreditAttribution: bbu23 at Ninja Coders commentedRebased MR 4174.
Comment #100
candelas CreditAttribution: candelas as a volunteer commentedIs there any patch for 10.2.1 ?
Thanks