Blocks seems to be another case where, besides having translatable blocks, we may like to have the option of defining different blocks -may be related or not- per each language.
So the first solution that I thought of was adding a language field to the block table -already added the db field, maybe too quick...- and selecting blocks for display depending on language, like what we did for path aliases. The problem with this option is that it won't allow to show a module provided block for two languages but not for others.
I.e. We have Spanish, French, English. Then we want to show the 'latest comments' block (provided by comment.module) for Spanish and French but not for English. This is not possible right now if we simply add a language field to the 'block' table, as this block should be linked to two languages instead of only one.
So I am thinking: Would it be a good option to have a different table 'block_language' so you can enable a single block for as many languages as you want, like for roles?
May be some more work, bit more complex, some performance impact -blocks table is queried for each page request and we'd have an additional join here-... But on the other side it would be a more 'complete' solution.
Please comment.
Comment | File | Size | Author |
---|---|---|---|
#100 | move-block-test-to-block-module.patch | 14.17 KB | Gábor Hojtsy |
#93 | move-block-test-to-block-module.patch | 14.18 KB | Gábor Hojtsy |
#90 | 135464-language_visibility-c90.patch | 20.51 KB | Gábor Hojtsy |
#87 | 135464-language_visibility-c87.patch | 19.96 KB | Gábor Hojtsy |
#86 | 135464-language_visibility-c86.patch | 20.01 KB | Gábor Hojtsy |
Comments
Comment #1
Roberto Gerola CreditAttribution: Roberto Gerola commentedHi Jose`.
> was adding a language field to the block table -already added the db field, maybe
> too quick...- and selecting blocks for display depending on language
Yes, I have implemented block support in localizer i this way, adding also
"Any" as optional language.
If a block has "Any" as language it will showed in every language.
Probably your proposal to have a list of languages for every block is more
flexible. For my point of view could be very useful also for nodes.
In every case, by the users feedback, it seems that many times you need to translate
only the block title and not the body.
Comment #2
Gábor HojtsyMoving to Drupal 7 queue. We don't have a separate code repository now, so no reason to have this separated as if someone is working on it.
Comment #3
Jose Reyero CreditAttribution: Jose Reyero commentedComment #4
z.stolar CreditAttribution: z.stolar commentedAssigning to myself for a while. I'll see how far I can get with that...
Comment #5
z.stolar CreditAttribution: z.stolar commentedIs there any rule-of-thumb as to whether to use another column in block table with a serialized array of languages, or a whole another table?
Comment #6
Jose Reyero CreditAttribution: Jose Reyero commented@z.stolar
Yes, there is, as you may be joining the language condition in you'll need another table, otherwise it won't work for queries. Also serializing has its own problems so it's always the last resource.
Comment #7
z.stolar CreditAttribution: z.stolar commentedThe attached patch is the beginning of the work. It contains the additions to the block configuration form.
It counts on an additional column in block table, where it serializes the language codes, but that's probably not the best practice, as it will be harder to alter queries later on (for example: to decide whether to display a block or not.)
Next steps:
- Add a table and change the patch
- Add the necessary code to decide whether to display a block
- Add languages to the blocks admin table (admin/build/block)
Comment #8
z.stolar CreditAttribution: z.stolar commentedCorrections in this patch:
- Added a table block_language, currently with no indexes.
- Values are correctly saved and retrieved in block configuration form
I'd appreciate some quick review, just to tell if I'm in the correct direction. Also, suggestions for indexes are welcome, though I think it's better to leave this to the end.
Comment #9
catchI'm not sure about this approach - there's already #79571: Allow blocks to appear in multiple regions which would allow for blocks to have multiple 'instances' - so for the use case of showing something in Spanish and French, but not English, that ought to get us in that direction (although I'm not sure if it's enough by itself).
So I'd lean towards adding a language column to the blocks table here to cover the most basic use case, then getting more substantial refactoring of the blocks system in which is being worked on elsewhere - which should allow for the cross-language requirements here to be covered in a more generic way.
The question is though, if those more substantial refactoring patches don't make it in, is an 'all' and single-language setting going to be enough in the meantime? If it's not, we should at least make sure that the join only happens with locale installed - and also benchmark it.
Comment #10
catchI'm fairly sure a SELECT on the block table with a WHERE on block_language is going to be hard or impossible to index properly. But that structure seems like the best approach for actually storing the block/language combinations, so maybe we just need to shift responsibility instead.
So the idea would be instead of {block_language}, we have a {locales_block} table - with the same schema, just owned by locale.module. Then a locale_block_visibility() callback is run just after the initial list of blocks is loaded, and does a separate single query per page on {locales_block}, which should be quicker than an un-indexed join. This would allow for blocks to be filtered out quickly before they get rendered, and means the only change to block module would need to be the hook addition - with everything else just copied over to locale.
Having said all that, I reckon we can do it in a separate patch - and let this go in pretty much as is - then shift visibility over to a refactored system at a later date - and having the block_language table like this would let that happen pretty cleanly.
Here's the spin-off issue: #370172: refactor block visibility
Comment #11
z.stolar CreditAttribution: z.stolar commentedCool. I'll use the patch at #370172: refactor block visibility#8 and add the necessary locale.module code.
Comment #12
z.stolar CreditAttribution: z.stolar commentedComplete the patch at #8 in #370172: refactor block visibility, plus patch #8 in this issue with a patch to locale.module, to implement hook_block_load.
Blocks are now filtered out on each page, if they're not enabled for the current language, or ALL languages.
Please review.
Comment #13
catchThe naming of the hook in the other issue is under dispute, but that doesn't make a lot of difference here. With the locale_block_visibility() you can just foreach ($result as $record) now that we're using dbtng/pdo - no need for db_fetch_array() which is on it's way out. I tried to draft a possibility for how this hook might look in http://drupal.org/files/issues/hook_block_visibility_0.patch - but that's untested and I think your approach is more readable.
Comment #14
Pasquallesubscribe
Comment #15
sunWith translatable fields in core, this patch (resp. the approach taken) is in competition with #430886: Make all blocks fieldable entities
Comment #16
plachI am afraid this will have to wait for D8 :(
Comment #17
Gábor Hojtsy@sun: reading up the discussions here, it looks like this issue is more about adding language specific visibility to blocks, not making them translatable per say. That is if block visibility survives the Drupal 8 context stuff. Retitling and tagging for that.
Comment #18
sourcesoft CreditAttribution: sourcesoft commentedIt's better this way than using ugly en/* in block visibility settings.
Comment #19
ArtusamakWill try to have a shot at it.
Comment #20
Gábor HojtsyYay! Yay!
Comment #21
ArtusamakAlright, here is the patch.
I created a new table dedicated for the visibility per language called block_language.
This table has the same structure as block_node_type and the same behavior. It adds a new visibility fieldset dedicated to the language.
The available languages are those enabled. If no language is selected, the block will always show.
The visibility alteration is done in the hook_block_list_alter and the documentation of this hook was actually implementing the block visibility per language (easy shot there).
I added this code in the language module. Not sure if it should go there or in locale. If i did wrong i'll update that.
Comment #23
Gábor HojtsyLooked at the code. Looks generally great, just "minor" comments.
All these places and more should use langcode, not language. We use langcode for language codes in D8.
Type? Looks like a copy-paste mistake.
This looks very odd but I guess it is a standard code snippet that we need to live with.
Comment #24
ArtusamakComments are integrated. Question though: I didn't replace the "language" string in the strings displayed in the user interface, should it be replaced there too by "langcode" or is "langcode" a term that we don't want to expose to the end user because it's not meaningfull?
I fixed the test by creating the table in the pre-imported database of the language upgrade path test. Should i write new assertions? If yes is the following test scenario ok?
* Configure a block visibility
* Assert that the block is displayed in the configured language
* Assert that the block is not displayed in the configured language
Thanks for reviewing.
Comment #25
ArtusamakHere is the asked for screenshot:
Comment #26
nonsieOne more minor - add a period at the end of
Sets up display criteria for blocks based on language.
Comment #27
ArtusamakFollowing Gabor recommandation. Attaching 2 screenshots, the "default" state of the form and the "set" state.
Reduced the width of the screenshot too.
Comment #28
ArtusamakGabor gave feedback in live.
I'm working on adding the hook_update_N() that is missing and the tests to detect that the table has been created and that the visibility setting is working.
Comment #29
Kristen PolI applied the patch and then had to start with a fresh database because there wasn't an update function yet... (I see that is being worked on ;)
The only issue I found was that when I created a block from scratch then the Languages fieldset/tab didn't show up. I had to save and edit the block for it to show up.
Comment #30
ArtusamakUpgrade path added.
Block creation visibility added.
Updagre path tests in progress.
Feature tests in progress.
Comment #31
dergachev CreditAttribution: dergachev commentedI decided to see how block.module handles the records in {block_role}, which are similar.
When a custom block is deleted, entries in block_langcode should be removed. See block_custom_block_delete_submit().
Same thing should happen when a language is deleted.
We should also consider implementing hook_module_uninstalled(), just as the block module does:
Comment #32
dergachev CreditAttribution: dergachev commentedNo time to roll a patch, but the following are also necessary:
Comment #33
saltednutCurrently we are not removing orphan entries from node... discussed with Gabor the orphan cleanup was deemed unnecessary.
Patch attached for #31 - block_langcode cleaned up when modules are uninstalled.
Comment #34
saltednutBlocks are showing/hiding around the site in normal pages and regions.
However, on the dashboard, a disabled block is still appearing. The content of the disabled block is 'empty' but the title of the block is still rendering.
This behavior seems inappropriate. See attached screenshot:
Comment #36
saltednutForgot to remove some local configuration from 135464-language_visibility-c32.patch.
This should be corrected in the attached patch. Also made adjustments to dashboard.module to accomodate for blocks determined disabled (set empty) for langcodes visibility.
Comment #37
saltednutignore last patch - contained unrelated code for this issue. (apologies!)
Comment #39
saltednutMaking changes to dashboard.module seems a bridge to far for this issue. I suggest moving the issues with dashboard not supporting 'block_langcode' table to a different thread.
@evolvingweb: Attached is the patch accommodating comment #31 - clean up {block_langcode} for modules uninstalled.
Comment #40
saltednutComment #41
dergachev CreditAttribution: dergachev commentedJust spoke with Brant and we agree that the dashboard behaviour he was concerned about in comment #34 is actually "by design", and it handles the language visibility setting fine. The dashboard module purposely renders "empty" blocks to the user, probably so they can administer. There's another issue [http://drupal.org/node/1009872] that's currently tracking this.
Comment #42
dergachev CreditAttribution: dergachev commentedSun's feedback:
Description is too long, too verbose.
Hide the tab if there's only 1 language. (in form_alter, check language_multilingual)
Form alter the "add new block" form too (present in #30)
rename table from block_langcode to block_language
write test for language_multilingual
Comment #43
saltednutThis patch is based on some of the work from patch c30 minus the tests. There is also a test from c24 that is not included.
Due to talks with Gabor and sun it was decided to call this table block_language instead of block_langcode.
Table renamed to block_language
Upgrade path added (unchanged from c30)
Block creation visibility added (implemented using less code thanks to sun & evolvingweb)
Comment #44
YesCT CreditAttribution: YesCT commentedEdit: was looking at the screen shots in comment 27.
I was looking for a similar pattern of selecting no check boxes means selecting all and thought we could reuse the same language.
I suggest something like what is used in the vertical tabs roles visibility settings page.
Show this block only for the selected role(s). If you select no roles, the block will be visible to all users.
I'll make a new patch with those words.
Comment #45
YesCT CreditAttribution: YesCT commentedsame patch as in comment 43 but changes
to
other than that, the ui looks good to me. it might be interesting to see what it looks like with a lot of languages.
Comment #46
YesCT CreditAttribution: YesCT commentedI took out spaces trailing at the end of lines, changed tabs to spaces and also reformatted indent pattern on some db_delete to match some other db_delete's I found elsewhere in core.
Comment #47
Gábor Hojtsyphpdoc should be shorter and on one line.
Comment #48
YesCT CreditAttribution: YesCT commentedphpdoc is one line and changed Create to Creates per http://drupal.org/node/1354#functions
line is now:
Comment #50
YesCT CreditAttribution: YesCT commentedI think this one applies now.
Comment #51
saltednut1. At this point we need tests written for a) upgrade path and b) add/edit block screens. Let me know if I am missing anything, Gabor.
2. A discussion was brought up by sun at Denver about the wording. The redundancy between the Title and Description "Show this block for specific languages" and "Show this block only if..." only adds to verboseness and does not add to usability. This is a problem inherited from the wording on the Roles tab. We should consider punting that format and coming up with new wording that is clear and concise.
Comment #52
ArtusamakOh some activity happened here since friday :)
I finally managed to fix the simpletest, you'll find in the attached patch a test for the upgrade and a test for the visibility.
Question: In the test i'm generating a custom block, for the block body when i'm using a random string it happens to have invalid markup, causing the test to fail. Should i create the body of the block with a filter or do you have any other suggestion to implement that?
About the verboseness, why not dropping the first part of the sentence?
Would become.
With the title it should be enough.
Comment #54
tstoecklerOne minor thing: It seems weird that all the form alters are in language.module, but we add JS to block.js and not language.js. I'm not JS-savy enough to judge whether it is actually possible to extend vertical tabs like that from the outside, but I thought I'd mention it.
Comment #55
ArtusamakRewritting the body generation.
Comment #56
Kristen PolI tested the patch in #55 and it works as expected. Specifically, I tested as follows:
1) added Burmese
2) added new block
3) restrict block to Burmese
4) restrict block to Burmese and English
5) restrict block to English
6) removed all language restrictions
and all scenarios worked. I also quickly scanned the code and nothing jumped out at me as needing to be changed.
Comment #57
sun1) 'langcode' never seems to be used as query condition or sort. Thus, 'langcode' unnecessarily increases the size of the primary key.
2) If we want to make sure that no duplicate rows exist at a database level, then we could add a unique index across the three columns. However, I'm not sure whether that is really needed.
3) We could leave the additional index for 'langcode', in order to speed up delete queries for the case when a language is deleted.
Apparently, this patch does not seem to contain code that deletes all langcode records when the corresponding language is deleted from the system. (There's only code for deleting corresponding module records when modules are uninstalled.)
4) These adjustments need to be done in the update function and in the schema function.
I looked at the ->fetchCol() implementation once again, and apparently, it always returns an array. Thus, this entire condition is superfluous.
@gabor: Is the t() valid here?
The description still duplicates the title/label. Let's merge the first sentence into the label:
"Show this block only for specific languages"
...and remove the first sentence from the description.
Regarding the second sentence, I'm not fully up to speed with regard to whether we're favoring direct speech ("you") or not. That said, the last part is definitely wrong ("users" vs. "languages").
I'd shorten the description to:
"Select none to show this block in all languages."
I'm not sure whether $language_interface is the correct language type/scope to filter by. Blocks contain content, so I'd rather expect them to be filtered by the current $language_content type/scope.
The tests do not seem to assert whether {block_language} records are properly deleted when
1) the providing module of a block is uninstalled
2) a language is deleted
"configuration" can be removed from the label/name.
Do we actually need Locale module for this test?
I'm not sure whether and why this upgrade test is needed. D7 did not contain a language visibility condition, and the module update does not attempt to migrate any data either (because there is nothing to upgrade), so this upgrade test does not really test anything other than bare essential block module functionality.
So unless I'm missing something big, this upgrade test can be removed.
Comment #58
ArtusamakOK, feedbacks taken into account, thanks for that.
I'll will discuss the t() implementation with Gabor tomorrow during the D8MI meeting and post the updated patch afterward.
Comment #59
ArtusamakStill need work.
Comment #60
Gábor Hojtsy@sun:
- We discussed deletion behavior in great detail at the sprint. When a language is removed, your nodes in that language or your users in that language are not removed. Neither they are made neutralized. This is likely legacy behavior. We might or might not want to remove the information about relation to removed languages. Sames goes for language relation of blocks. This is thankfully not the main block data itself (unlike nodes or users), so it is much more lightweight to remove them. If you believe we should, we can put it in there. It is going to be inconsistent with how we keep language information other places when a language is removed, but that whole thing is inconsistent with the rest of Drupal.
- t($language->name) should not be good anymore. CMI translation will need to be used when needed, once available.
- On the description for visibility, I believe YesCT unified that with the roles descriptions (see http://drupal.org/node/135464#comment-5780188), so I think as long as we use the same pattern here, it should be a common approach; if we deviate from that, it will look odd/nonstandard IMHO.
- Otherwise agreed.
Comment #61
ArtusamakNew patch applying feedbacks described above.
I removed the t() and added a TODO to note that it needs work related to CMI.
About the description, i kept the one from YesCT but remove the first part used in the field title. It makes more sense to avoid this redundancy. Is it ok?
@Sun we need locale to be able to have the drupalGet() assertion working properly with the language option. (Otherwise the language is not changing).
Ready for new feedback.
Comment #62
Kristen PolI applied the patch without errors. Then, I tested the same scenarios as in #56 with no obvious errors (from the UI). But, this time I looked at the
block_languages
table while I was doing the configuration and found that theblock_languages
data wasn't removed when:It is not clear based on #60 whether this functionality must be in there (since legacy language data persists for deleted nodes). Perhaps @sun needs to comment on that?
If the
block_language
data doesn't need to be deleted when deleting the block or language, then this is RTBC in terms of functionality. Though, someone might want to check through the code.Comment #63
Gábor HojtsyRight, looks like based on reviews, we want to remove language vs. block info after all when blocks are removed or languages are removed.
Comment #64
ArtusamakAlright, i added the code to clean the db entries when a language is deleted and when a custom block is deleted.
Comment #65
Kristen PolI repeated the tests from #62 and everything worked as expected. Everything that worked previously still worked and now the appropriate records from the
block_language
table are removed when the block or language is deleted.I won't mark RTBC because the code needs to be reviewed by a core person... I did scan the code quickly and noticed quite a few lines exceed 80 characters.
Comment #66
Gábor HojtsyI've been thinking about this problem of the JS being in block module and the rest being in language module. We have seen similar problems before with node module, comment module, etc. In Drupal 8, we moved language handling entirely to the respective modules instead of locale/language module handling it for them. So with that in mind it seems logical to put this functionality entirely in block module. Related issues for supporting this direction:
#1236680: Move path language settings from Locale to Path module
#540294: Move node language settings from Locale to Node module
#1415764: Untangle comment module and locale module
etc. It is likely going to be much less code but more intertwined with the existing block module code. That is in line with how low level / built in we consider language support should be in Drupal 8.
Comment #67
YesCT CreditAttribution: YesCT commentedI would suggest keeping wording similar to roles settings page. Or, if we think a new pattern is needed, to change it in both (and other) places. If we come up with better wording pattern here, I suggest opening an other issue to see if it can improve the roles settings page too.
Comment #68
ArtusamakOK will work on it.
Comment #69
ArtusamakThe attached patch is moved the feature implementation into the block module. I let the tests in the language module, i believe it makes more sense to have them there because it's tight to the language module.
Let me know if i have to change that.
The patch is also redefining the description on the same pattern as roles use it.
I hope it will make it through this time! :)
Comment #71
ArtusamakReformatting the patch, also rebasing with an up to date 8.x.
Comment #72
Gábor HojtsyI think this looks pretty good. Just two notes:
I think this could be topic of debate, but I'd consider blocks to be interface and should therefore use the interface language.
All functions/methods should have one line summaries. Good twitter skills come in handy here, except you are mostly not allowed to abbreviate or make grammar mistakes :)
@Kristen: want to take this for a test drive too? :)
Comment #73
sunheh, quoting myself from #57:
In the end, I guess that you'd potentially want to be able to filter by one of both (or even both) in advanced use-cases. The new block plugins might even allow for that. But until then, we need to decide what's more appropriate for this simple implementation.
For built-in Drupal core functionality, I don't think it actually matters, since AFAIK, there's only one language negotiation configuration, which is applied to the interface and content language in one shot, so they are the same in most cases.
@plach: Could you make the final call on this?
Comment #74
Gábor Hojtsy@sun: the blocks for account login or registration or menus is translated by the interface language, so that is why I assumed that would be more applicable. This is easily changed either way, so I can agree with content language if that is what people prefer.
Comment #75
plachI agree. Not sure about the UX implications, but what about adding an element allowing to choose among all the configurable language types? This way if we make content language configurable, which is likely to happen at some point in D8, we are ready to support this use case.
Comment #76
andypostI have another thoughts:
1) each block is unique by it's application usage so there's should be difference in config related to content or interface language.
2) this functionality makes sense only on multilingual context so having this code in block.module is wrong (#10 explains deeper) also WSCCI introduced context seems more suitable for this purpose
In #66 Gabor explains that we should have this code in block but having another table once most of sites are single language is nonsense
Suppose this issue should have more focus on UX implications first
Comment #77
Gábor Hojtsy@andypost: yes, this code only makes sense in multilingual context. Node, user and path module also has lots of code which is only applicable there. The concept for Drupal 8 is that just like contrib modules, core modules would need to implement this on their own instead of implementing most of it on their own and then some injected from the outside, like it was for node, user and path in Drupal 7. Since they need to do their data handling, list filtering, etc. for themselves, it makes sense to have this code with them.
Related: we have a host of issues at #1498634: [meta] Define revision/translation SQL schema for core entities (no patch) where the current plan is to have multiples of some core tables for translation purposes.
Comment #78
Kristen PolI'm just looking at this (was Spring break last week :)... do you still need testing for #71 or should I wait on any final tweaks based on the last few comments?
Comment #79
Gábor HojtsyI think if we want to introduce the language type selector, it should be a dropdown or radio button group above the language list I assume. Then how would we store that data I'm not 100% sure. On each record of the block language table? I assume the UI should not support combined filtering by multiple languages at once... I feel this could easily complicate this too much (ie. delay this getting in for longer, while we still have a great opportunity ATM to get it in).
Comment #80
ArtusamakJust to keep a trace of what is discussed quoting the D8MI IRC meeting.
Comment #81
Gábor HojtsyAdding language type support:
1. New type column in block_language.
2. Found out that you could not tie a block to multiple languages at once, because the primary key on the table did not allow for that. Expanded primary key.
3. While the DB (and the block visibility logic that I've updated) supports multiple type-language combos, the UI is built to allow for one language type selection for all the languages for a block. Much simpler UI.
4. The type selector is hidden if there is only one language type configurable (which is the only thing that can happen in core at this stage btw, there is no core way to make more types configurable so far).
So this ties the block to the only configurable language type if there is one and offers a selection if there are multiples. UI did not change for the core case. If there are more language types (again, does not happen in core at all now), then you get this UI:
Interdiff attached for your reviewing pleasure. @all: please review!
Comment #82
Gábor HojtsyLeft a little bitty test code in that patch :) This line removed now:
:) This was used to create the screenshot btw :)
Comment #83
sunMissing space after foreach.
This additional query looks bogus and like obsolete debugging code; the result overwrites $default_language_type.
Typo in language.
It's not really ideal that this code block cannot be freely moved within the context/visibility filtering code, because it skips to the next item on positive match (so any additional filtering code behind it would not run).
However, since most of this code will likely be refactored for the new D8 block system either way, I guess we can leave it that way.
Comment #84
Gábor HojtsyFixed the typos and leftover debugging code. I agree the logic not possibly freely moved around is probably very temporary. Any other concerns?
Comment #85
sunSorry, forgot one issue. RTBC after fixing this:
The proper way to do this is:
on the otherwise always identical #type radios form element. That makes sure that other modules do not have to use complex conditional code when trying to enhance or alter the form.
Comment #86
Gábor HojtsyI definitely had that at one point but found that it would complicate the submission workflow. Let's see, just changed the form.
Comment #87
Gábor HojtsyOk, I must have had some other issue when working on it back then :) Also fixed the two phpdoc issues I've noted in #72 above, so I don't have any more outstanding issues to fix I believe :) Good? :)
Comment #88
sunThanks!
Comment #89
Dries CreditAttribution: Dries commentedGreat feature!
This patch needs a quick re-roll.
Also, do we want to update CHANGELOG.txt?
Comment #90
Gábor HojtsyRerolled. Added short changelog entry.
Comment #91
Dries CreditAttribution: Dries commentedCommitted to 8.x. Thanks!
Comment #92
catchWhy is all the code added to block module, but the tests added to language module?
Comment #93
Gábor HojtsyYou are right. Moved the tests to block module. Changed group to 'Block' to appear there and removed locale module from list of modules enabled for the test. There is no use/need of locale module there, its about UI translation only now (except those pesky date formats). Passed for me, so should be directly RTBC if passes. It is just a logical copy-paste.
Comment #96
Gábor HojtsyRestoring spam changes.
Comment #97
Gábor Hojtsy#93: move-block-test-to-block-module.patch queued for re-testing.
Comment #98
Gábor HojtsyTrivial.
Comment #99
sunWithin Block module, this test case needs to be in the Block namespace; e.g.:
BlockLanguageTestCase
(Yes, we're not fully consistent with that and there are a couple of bad test case names throughout core, but those need to be fixed and don't serve as examples ;))
Comment #100
Gábor HojtsyDid exactly that. :)
Comment #101
catchThanks! Committed/pushed to 8.x.
Comment #102
Gábor HojtsyThanks.