Layout names and region names in layout module are not translatable [#1939300]

Problem

Region names from theme .info files have been translatable forever. Localize.drupal.org extracted them for good, translators translated so localized admin interfaces could say "First sidebar" or "Footer" in the admin's language. With the layout module defined static layouts, this is not possible anymore. The layout label and the region name are both only check_plain()-ed for output (in layout_page_view() and layout_page_list() respectively).

Proposal

We should figure out how to localize these. Should the plugin t() them when providing the definition or should layout module assume it would need to t() them. t()-ing in layout module could be an issue for any dynamic layouts, which are possibly defined in config or other parts of code. Those might be created in a non-English language and translated via the config system for example. So ideally the plugin would return localised name and region labels.

Comments

Comment #1

Gábor Hojtsy

he/him

Hungarian

Hungary

CreditAttribution: Gábor Hojtsy commented 11 March 2013 at 08:26

BTW the corresponding issue to support extraction of these strings in potx (and therefore localize.drupal.org is #1939306: Support for Drupal 8 static layout .yml files).

Comment #2

EclipseGc CreditAttribution: EclipseGc commented 11 March 2013 at 15:33

yeah, I'd prefer to ignore that there are yml files involved here. I think we can probably do some work in the base class for layout plugins to make the value of any region in a list translatable. Probably a few more elements in the yml files that need to be exposed as translatable too, but I think we can probably encapsulate a lot of that w/o doing something crazy.

Eclipse

Comment #3

Gábor Hojtsy

he/him

Hungarian

Hungary

CreditAttribution: Gábor Hojtsy commented 11 March 2013 at 15:41

My thinking is if we t() in the plugin then you cannot really retrieve the plugin without it being translated to the page's language. If we t() later, then we might t() data coming from a plugin that already translated config (eg. user defined regions in a layout builder). So sounds like t()-ing in the plugin sounds better. Any better ideas?

Comment #4

EclipseGc CreditAttribution: EclipseGc commented 11 March 2013 at 15:58

Yeah I think that's true, we can probably do this in the derivative class, and that seems really reasonable to me, and we could pass a context there that says they're layout region names.