Updated: Comment #0
Problem/Motivation
In #2056513: Remove PluginUI subsystem, provide block plugins UI as one-off, a new annotation key was added to Block plugins: category
This would allow future categorization of blocks, but initially was just defaulted to the module providing the plugin.
Now that would like to use this in the UI in #2058321: Move the 'place block' UI into the block listing, we should make it a proper string, and translatable.
Proposed resolution
Use @Translation in annotations, and t() in any dynamic additions of category
Remaining tasks
Write patch
User interface changes
Proper strings for block categories
API changes
Is this an API change? No idea.
Related Issues
Comment | File | Size | Author |
---|---|---|---|
#32 | block-2060859-32.patch | 5.46 KB | Gábor Hojtsy |
#29 | block-2060859-29.patch | 5.47 KB | tim.plunkett |
#23 | block-2060859-23.patch | 5.47 KB | tim.plunkett |
#23 | interdiff.txt | 577 bytes | tim.plunkett |
#20 | block-2060859-20.patch | 4.9 KB | tim.plunkett |
Comments
Comment #1
Gábor HojtsyWhere would this string appear on the UI?
Comment #2
EclipseGc CreditAttribution: EclipseGc commentedIt's the category title on the right side. Instead of forcing this to be the provider, you're giving people the ability to actually group blocks by something more relevant, and it also lets you expose this from the ui. Views (for example) will almost certainly want to take advantage of this. I could see Custom Blocks doing it too.
Eclipse
Comment #3
tim.plunkettModulesListForm doesn't seem to translate the human-readable module name:
So I'm not sure if that should be wrapped in t() or not.
This contains the change to SystemMenuBlock that is in #2058321: Move the 'place block' UI into the block listing, except that sets it to "menu" instead of @Translation("Menu")
Comment #4
Gábor HojtsyI think there has been some fierce discussions historically about whether module names should even be possible to be translated. They are made available for translation on localize.drupal.org but maybe not actually translated on the UI. It is important that people know they use the 'Views' module and not 'Ansichten', 'Blick', or 'Meinung', all of which are different translations of the words 'View'/'Views'. That helps finding tutorials, updates, and so on. Once they become exposed as block categories, that may be a different question is we deliberately want to deviate from them being module names and be free-form plugin provided strings instead. Translatability applies then.
Comment #5
Gábor Hojtsy#152375: Implement translatable module names (with context) has lots of the arguments around module name translation. It was marked won't fix more than once....
Comment #6
tim.plunkettConfirmed with @Gábor Hojtsy that this was okay.
Comment #7
EclipseGc CreditAttribution: EclipseGc commentedSo, I don't really have an opinion with regard to the whole translating languages thing. I expected us to process in a "Miscellaneous" option into the plugin definitions & just allow plugins to override that with specific annotations of what category they belong in. Anything beyond that is over and above what I was expecting here. I'm fine either way, and in general the patch is looking ok to me. If Gabor's on board with your specific translation approach for module names in the UI, then I'm fine with that too.
Eclipse
Comment #8
tim.plunkettReroll, no change.
Comment #9
benjy CreditAttribution: benjy commentedYeah this looks good, a few small doc things and then this is RTBC for me
Would this be better as, "An array of...."?
Since this can also return a machine name, should we improve this? Or maybe the description above.
Comment #10
tim.plunkettFair points!
Comment #11
benjy CreditAttribution: benjy commentedLooks good.
Comment #12
alexpottI'm wondering whether or not we should be using the translation context system here? For example,
t('Block')
exists in\Drupal\aggregator\FeedStorageController
.Comment #13
tim.plunkettNo idea.
Comment #14
tim.plunkettRerolled for #2065721: Add a dedicated @Block plugin annotation
Comment #15
Gábor HojtsyCurrently the module names are extracted from .info.yml files but not assigned any context. If this code would use a context when translating, that would mean that (a) the annotation for the category should also use a context (b) the .info.yml extractor should extract the module name ALSO with that a context for this. So while doing the context would possibly be useful, its not trivial work :) Also it would expose all the module names once more to translators under a different context name. Not sure that is useful.
What would the context be? "Block category"?
Comment #16
tim.plunkettI think if anything, then FeedStorageController needs some context.
Comment #17
catchThis should use system_get_info(), no need to rebuild.
Also needs a re-roll for $this->t()
Comment #18
tim.plunkettThere is no extra rebuilding here, all we're doing is not checking it against getModuleList()...
But that's your call.
Uploading both just in case.
Comment #19
catchSorry wrong function... https://api.drupal.org/api/drupal/core!modules!system!system.module/func...
Comment #20
tim.plunkettHot damn, I didn't know we could do that. ModuleInfo++
Comment #21
benjy CreditAttribution: benjy commentedIf the bot likes it, looks good to me.
Comment #23
tim.plunkettWTF.
I don't even want to know.
Comment #24
BerdirHm. that function and class is removed in #2025779: Remove ModuleInfo as it is no longer necessary as it was considered to be no longer necessary (by @catch :)) as we don't store that much in .info files anymore. As it didn't get in in time, we might want to keep the function but drop the caching.
Comment #25
catchI don't think we need CacheCollector there, but we could use a persistent cache for this still I think. I thought system_get_info() had a basic persistent cache (which is why I originally mentioned that function), but clearly it doesn't. Everything about system info is still a big mess...
Comment #26
tim.plunkettSo where do we go from here? I'm inclined to just go back to 18B, system_get_info('module') for now, in case #2025779: Remove ModuleInfo as it is no longer necessary happens, and if not, add a persistent cache in another issue.
Comment #27
tim.plunkett#18: block-2060859-18-B.patch queued for re-testing.
Comment #28
catchArgh sorry. Let's do that and open a separate issue to add a simple cache to system_get_info().
Comment #29
tim.plunkettOkay then.
Comment #30
Gábor HojtsyLooks good to me.
Comment #31
webchickSeems like catch's concern is resolved here, Gábor is +1. Looks good to me, too.
However, seems to no longer apply. :(
Comment #32
Gábor HojtsyThis was an easy reroll :) The system menu block category annotation change was the only thing that did not apply anymore.
Comment #33
webchickCommitted and pushed to 8.x. Thanks!