Ibexa DXP Discussions

Community discussion forum for developers working with Ibexa DXP

Should SiteAccess names be translatable or not?

Hi eZ Community!

We plan to introduce human readable SiteAccess Names into the product. The main goal is to replace the SiteAccess code by a name easier to read, understand for the editor.

For instance in the preview interface with the SiteAccess selector:

For more on this user story, here is the ticket: https://jira.ez.no/browse/EZP-28806

I would like to know if translating the SiteAccess names is important for your projects. Feel free to answer the poll, comment and give some examples.

  • I don’t need translation for SiteAccess names
  • I want to translate SiteAccess names

0 voters

just curious about one thing from the screenshoot. is there any difference then between the select Siteaccess and the language selector we can see below the “person” icon?

I voted for “I don’t need translation”, but let me explain my choice.

My vote was a personal one. I, for one, don’t care if the siteaccess name is human readable or translatable, because the thing I care about in the interface is to see the siteaccess identifier so I can quickly locate it in the settings if I need it, without having to go look through every one of the siteaccesses defined to find the one with the correct translation (think of sites with hundreds of siteaccesses, or the sites with multiple siteaccesses for a single site that have gone through couple of stages of redesign).

BUT, I realize that there is value in displaying human readable and translatable siteaccess names for editors who do not care about the fact that siteaccess is really_called “front_site_cro_2017”.

So my real answer would be, while I think that showing identifier is utterly important and should not be removed, I would like to see both in the interface, in the form of, for example, “Croatian frontend (front_site_cro_2017)”.


Actually, the language selector is part of the frontend design.
The only relation is: SiteAccess A has english as primary language, so English is selected on the frontend.

Thanks @emodric for this suggestion. This way of naming can help editors and developers.

1 Like

I voted for “I don’t need translation” too.

It is great to have a Human name for a siteaccess but a translation of it seems useless as a siteaccess as a Main Language I would say.

Most of the time already, unless it changes, but a SiteAccess is tied to a Language.
The only reason would be in this case:

You are on the site_en, and you want to switch to site_fr, you would site that list

  • French (site_fr)
  • English (site_en)
  • Spanish (site_es)

On the site_fr you could want to seei:

  • Français (site_fr)
  • Anglais (site_en)
  • Espagnol (site_es)

=> here you will need a translation.
Also, speaking of translation, see can be already achieve using a translation key.

On the front-end, we always make it show the same language list on every siteaccess. That is:

  • English
  • Français

Because you should only click to the Français siteaccess si tu parles français.

1 Like

Voted no, but supporting the suggestion by @emodric

I voted yes. Users are not machines. It should be available but optional, we should not be closed.

I would apply the same idea for image variation and allow community managers to see human readable image variation…

But … there is a lot of functionality much urgent that are missing to eZ Platform… before thinking of this.

@sylvain.guittard Was this ever implemented?

Yes it has been implemented and it’s documented :slight_smile:


1 Like

Thanks @sylvain.guittard !