Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-28806

As a developer I want to define the SiteAccess name

    Details

    • Story Points:
      1

      Description

      Context:

      In order to simplify the interface and create a better editorial experience, we would like to "hide" the SiteAccess code. This value does not make sense for the end user. It will be better to display the name of the website (human readable).
      Interfaces where this can apply:

      • Page builder (SiteAccess switcher in the top navigation)
      • Content Preview (SiteAccess switcher in the dropdown menu)
      • Page creation modal window (when coming from Content Structure)

      Technical

      It was decided that we would keep using the translation system, as was done for field definition groups and custom tags.
      The domain is called `ezplatform_siteaccess`, and the siteaccess name is used as the key.

      In app/Resources/translations/ezplatform_siteaccess.yml:

      fr: Tatestfull Planet France
      en: Tastefull Planet
      

        Issue Links

          Activity

          Hide
          Sylvain Guittard added a comment -
          Show
          Sylvain Guittard added a comment - ping Bertrand Dunogier Andrzej Longosz
          Hide
          Andrzej Longosz added a comment -

          From my POV translatable option makes more sense. I'm assuming fr and en are SiteAccess names, right?

          Technically it could be a file app/Resources/translations/siteaccess.en.yml where en is current locale.
          Translation key / value could be:
          ezplatform.siteaccess.en.label: 'Tasteful Planet'
          ezplatform.siteaccess.fr.label: 'Tasteful Planet France'
          where en and fr are SiteAccess names respectively.

          Side note: I haven't found any Yaml translation files after all, so I wouldn't recommend breaking convention, let's stick to xliff (though personally I prefer Yaml).

          The second option is of course also doable and probably requires less time.

          Show
          Andrzej Longosz added a comment - From my POV translatable option makes more sense. I'm assuming fr and en are SiteAccess names, right? Technically it could be a file app/Resources/translations/siteaccess.en.yml where en is current locale. Translation key / value could be: ezplatform.siteaccess.en.label: 'Tasteful Planet' ezplatform.siteaccess.fr.label: 'Tasteful Planet France' where en and fr are SiteAccess names respectively. Side note: I haven't found any Yaml translation files after all, so I wouldn't recommend breaking convention, let's stick to xliff (though personally I prefer Yaml). The second option is of course also doable and probably requires less time.
          Hide
          Adam Wójs added a comment -

          +1 for the second option

          Show
          Adam Wójs added a comment - +1 for the second option
          Hide
          Steve Konrad added a comment -

          would also prefer the second option as it could be that there is no main language and the names are required to be translated depending on the language of the currently active siteaccess.

          Show
          Steve Konrad added a comment - would also prefer the second option as it could be that there is no main language and the names are required to be translated depending on the language of the currently active siteaccess.
          Hide
          Sylvain Guittard added a comment -

          Steve Konrad: not sure to understand the use case. Could you please provide more details or give an example of configuration? Thanks.

          Show
          Sylvain Guittard added a comment - Steve Konrad : not sure to understand the use case. Could you please provide more details or give an example of configuration? Thanks.
          Hide
          Steve Konrad added a comment -

          Hi Sylvain, I missread the "second option" to be the suggestion made by Andrzej.

          So using translation to generate the displayed name of the siteaccess might be the best solution. Either of the options mentioned in the tickets description would work as a fallback of sorts (if the translation is missing). In this case I'd prefer the first option as it is closer to the configuration of the siteaccess itself.

          In my opinion the names (most of the time including language and/or country) should be readable by all editors and thus are required to be translatable. Just thinking of the different characters some languages use (cyrillic, roman, etc.).

          Show
          Steve Konrad added a comment - Hi Sylvain, I missread the "second option" to be the suggestion made by Andrzej. So using translation to generate the displayed name of the siteaccess might be the best solution. Either of the options mentioned in the tickets description would work as a fallback of sorts (if the translation is missing). In this case I'd prefer the first option as it is closer to the configuration of the siteaccess itself. In my opinion the names (most of the time including language and/or country) should be readable by all editors and thus are required to be translatable. Just thinking of the different characters some languages use (cyrillic, roman, etc.).
          Hide
          Sylvain Guittard added a comment -

          Regarding the votes on https://discuss.ezplatform.com/t/should-siteaccess-names-be-translatable-or-not, we will add the translation on the SiteAccess names.
          Suggestion from Edi Modrić (displaying SiteAccess names and SiteAccess code) is a very good. Example: Croatian frontend (front_site_cro_2017). This solution covers Editors and Developers needs.

          Bertrand Dunogier: Could you please take care of the technical part? Thanks

          Show
          Sylvain Guittard added a comment - Regarding the votes on https://discuss.ezplatform.com/t/should-siteaccess-names-be-translatable-or-not , we will add the translation on the SiteAccess names. Suggestion from Edi Modrić (displaying SiteAccess names and SiteAccess code) is a very good. Example: Croatian frontend (front_site_cro_2017) . This solution covers Editors and Developers needs. Bertrand Dunogier : Could you please take care of the technical part? Thanks
          Hide
          Bertrand Dunogier added a comment -

          I have updated the description in regards to the implementation aspects.

          Show
          Bertrand Dunogier added a comment - I have updated the description in regards to the implementation aspects.
          Show
          Dawid Parafiński added a comment - https://github.com/ezsystems/ezplatform-admin-ui/pull/449
          Hide
          Dawid Parafiński added a comment -
          Show
          Dawid Parafiński added a comment - This needs doc, Sylvain Guittard Dominika Kurek
          Show
          Magdalena Zuba added a comment - doc PR: https://github.com/ezsystems/developer-documentation/pull/291
          Show
          Barbara Grajczyk added a comment - PR merged: https://github.com/ezsystems/ezplatform-admin-ui/commit/2ab2aa1888b0259f289ebc8a24f76c8bbfa5591a

            People

            • Assignee:
              Unassigned
              Reporter:
              Sylvain Guittard
            • Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: