Default 'pages' content type name change has no effect on backend UI

[sbonardt]

When I change the 'pages' content type name and singular_name fields to have them set in another language the change has no effect on the UI.

So when setting the values to this: (Dutch/NL names)

pages:
    name: Paginas
    singular_name: Pagina
    fields:
        title:

gives me a UI that still has the linktext in the backend sidebar as "Pages", Bekijk 'Pages', Nieuwe 'page'.

But the slugs do get updated to /pagina/ and /paginas/! (see screenshot)

I expect the translated names to appear in the UI as well.

Note:
If I create a new content type "articles" and give theme the dutch name "artikelen" and singular_name "artikel" these get printed properly in the backend UI. "Artikelen", Bekijk Artikelen, Nieuwe Artikel.

[rarila]

All backend contenttype localisation is done using menu Settings: Translations | Contenttypes. (Ends up in bolt/app/resources/translations/nl_NL/contenttypes.nl_NL.yml in your case)

[sbonardt]

Exactly, that's the weird thing about it. "Artikelen" does get used in the UI. How is that possible if it's not being used from the translation file "bolt/app/resources/translations/nl_NL/contenttypes.nl_NL.yml" as thats all commented out?

[bobdenotter]

I still think this is an issue. @rarila: while technically you are correct, this issue is confusing and hard to understand for users. So in that regard it is broken.

[rarila]

Was looking that up at the moment. In latest version there is "Nieuwe pagina" in contenttypes.nl_NL.yml. So, @sbonardt What do you have there?

@bobdenotter I always told you it is a broken design to have localisation data in two places ;-) This gotta be fixed in 3.0

[bobdenotter]

The thing is that sbonardt explicitly defines the name: for the contenttypes, and for one of them the name is ignored, while for the other the name is used as defined in contenttypes.yml. This is not something that can be explained to people.

[sbonardt]

jep. that's it. :)

I have nothing in my NL translation file (it's all commented out) but 'articles' gets "translated" (the name and singular name appear to be used, while for pages it doesn't seem to get used. If this is in core translation or not, I wouldn't know. And if I look in the translation file for my language it's not there.

[rarila]

@sbonardt If you create a new contenttype then there's no translation at all and a generic one is used (that with some luck is grammatically halfway correct). You have to add the translation by yourself then.

@bobdenotter Yes you can't. That's why all localisation stuff has to go in the localisation part (contenttypes.xx_XX.yml) and only the definition of database has to be in contenttypes.yml. Then it's simple

[rarila]

@sbonardt The generic ones are to be found here

[bobdenotter]

I know we've had this discussion before, and my opinion was overruled, but it really doesn't make any sense to me. :-/

[sbonardt]

Hi @rarila thanks for the link.

As example, the translation for 'New %contenttype%' is there. It's new: "Nieuwe %contenttype%"

So the "New" part is translated to "Nieuwe" but the %contenttype% not. However, I do see a translated name in the UI for one content type "Artikelen" but not for the other "Pages". How come "Articles" does get translated to "artikelen" and "artikel" but "Pages" does not get translated to "paginas" and "pagina"? Where can that be found? They both are fairly generic to me.

pages:
    tablename: pages
    name: Paginas
    singular_name: Pagina
    fields:
        title:
            type: text
            class: large
            group: content
        slug:
            type: slug
            uses: title
        image:
            type: image
        teaser:
            type: html
            height: 150px
        body:
            type: html
            height: 300px
        template:
            type: templateselect
            filter: '*.twig'
    taxonomy: [ chapters ]
    recordsperpage: 100


# Articles
articles:
    name: Artikelen
    singular_name: Artikel
    fields:
        title:
            type: text
            class: large
            group: content
        slug:
            type: slug
            uses: title
        image:
            type: image
        teaser:
            type: html
            height: 150px
        body:
            type: html
            height: 300px
        template:
            type: templateselect
            filter: '*.twig'
    taxonomy: [ tags ]
    recordsperpage: 100

[rarila]

@bobdenotter It's as simple as:

• Either Bolt is single language and all localisation stuff is in contenttypes.yml. But then there has all this other stuff (like "New …") to be added there, too.
• Or Bolt is localisable. Definition here, localisation there. Probably not that comfortable for single language installations, but a clear design, easy to explain. (and comfort could be added per software)
• Or you have both worlds were you can add localisation in both places - But then you end up having to explain that to the user and have to decide which one overrules which one. And you can argue in both directions in that case as you also can say, I've edited contenttypes.xx_XX.yml to 'paginas', why is there still pages displayed.

[bobdenotter]

@rarila I actually agree with most of that. The only thing I disagree with how it currently works is that (IMHO) something that's explicitly overruled in contenttypes.yml should get precedent over something that's defined in other files.

We do the same with a lot of other stuff. For example, the global config.yml can set a listing_template, as well as the theme's config.yml. However, if we set it for a specific contenttype, that setting will take precedent over the others. In my mind that makes sense, and it's confusing that the name: doesn't share this behaviour.

tl;dr: I agree with how it works, i just think the priority of selecting a value should be the other way around.

[rarila]

@sbonardt Ok, step by step? I know your contenttypes..yml already.

• Do you have an contenttypes.nl_NL.yml?
• If yes, is there an entry contenttypes.pages.new?

[sbonardt]

Do you have an contenttypes.nl_NL.yml? Yes, but it's the default with everything commented out
If yes, is there an entry contenttypes.pages.new? jep, commented out #

My two cents...

I see it more as defining a content type with a label then part of a translation. Just like with fields in a content type where you can make the label whatever you want, I see the name and singular_name fields for the content type as well as a sort of label field. I would like to see that 'name' field come back in the interface regardless of any translation I guess. It's the basis for my website setup.

Then on top of that you can optionally set a translation for that field in the translation file to be used wherever if you have your website in another language as well. But I only have one language for this site.

My expectations were that the name I fill in in the content type definition will get used.

So if I fill in "Oompah Loompahs" as name for content type 'articles' I want to see "Oompah Loompahs" in the backend CT's menu on the left (and 'New "Oompah Loompah, etc.) I can translate that -when and if I would like to at some point- to another language if needed.

I hope this makes sense and clarifies it a bit.

[rarila]

@bobdenotter But if config overrules localisation then an added localisation would never take effect as always the value from contenttypes.yml would be used.

The only solution is to strictly divide configuration from localisation and get back comfort by software.

We live in an ajaxy world today so editing (all) localisations in parallel on the same page where you edit the contenttype is possible. E.g. when your cursor is on pages.name.title a button "Localisation" could get enabled and when you press it a dialog pops up where you can enter the translations… many possibilities to make that happen. You also could mix in the localisation on load and separate it again on save so that you end up with a localisation free contenttypes.yml and all localisation gone into contenttypes.xx_XX.yml…

[rarila]

@sbonardt ok, if you don't have anything in contenttypes.nl_NL.yml then there's something wrong, how the translation is handled.

As for the rest, the mixing is the thing that makes it that difficult to explain what happen. And as I said above, if the config overrules the localisation you can later add as much translations as you want, you will never see them, as you will only see the one in the config. So you either make it the other way round or you have to define somewhere, that the config is the localisation for language XX (add "locale: XX" to contenttypes.yml), otherwise you can't handle it. But that doesn't make things easier and brings a lot of duplicated code and exceptions in the codebase. And those exceptions blow up the source and open the door for errors as you just found out.

Also this generic translation won't work for all languages, It probably works out for relatively good for English, I don't know for Dutch. But for German it's "Neue Seite" (new page) and "Neuer Artikel" (new article) – you notice the 'r'. I do not even want to imagine what problems will occur on more exotic languages. So (in most cases) you have edit the translation anyway as the generic one simply doesn't get it. The generic one is only there to get something (almost correct) displayed in the first place und as an template to easier generate the actual translations where you with some luck only have to edit a few characters.

So having the localisation inside contenttypes.yml makes more problems in many areas as it solves.

[sbonardt]

But I don't want anything translated by the CMS...

That's why there's nothing in the translations file

I want the backend to print out exactly what I feed it, when I give something a name/singular_name.

I already translated it and filled in the translated word in contenttypes.yml. I don't want the CMS to translate it, or to state something in English first in contenttypes.yml (default Bolt language) first and then add an translation file to have the proper name for it, when I just have 1 language for my website.

Maybe my choice of words made this go too far into the translations side of the CMS, as I see now the discussions moved a bit too much to the translations side of things. Or maybe it's just a translations thing and the choice where to put these as you guys stated. Doesn't however take away the fact that I want to see the name back as I stated it in the first place.

[rarila]

Anyway, things won't change for 2.2 (old) and won't change for 2.3 (feature freeze). One thing is clear, v3 needs a major overhauling in this respect, in what direction ever. (and that will be changes that break BC).

For your case you could either create a contenttypes.nl_NL.yml (Bolt does that for you almost automatically anyway – although there seems to be a bug that english example translations are created, instead of those of the selected locale. Gotta look into that - hack to solve that meanwhile: copy the content of messages.nl_NL.yml into messages.en_GB.yml). Or at least add contenttypes.pages.name.plural and contenttypes.pages.name.singular there.

Removing contenttypes.en_GB.yml could probably help in your case, as then the English fallback can't be accessed. (haven't tried that)

[sbonardt]

OK. Thanks for checking out a workaround for now @rarila .

V3.0 it is then, for this one.

[rarila]

I guess that's gonna be a hard piece of work

[bobdenotter]

Yes, It'll be pretty hard to do it right. As far as I can tell, none of the "big boys" do it right either. Mainly because we need to work around an issue that's simply not present in english. (ie. different prefixes for gendered nouns)

Anyhow, the issue should be somewhat alleviated by #4163, when it lands. :-)

[SvanteRichter]

Should have been somewhat alleviated by #4163, but leaving this open as this really it is a problem (and annoys me to no end).

[GwendolenLynch]

Maybe @rarila and I can collaborate on a branch during 3.0-dev, but someone to help with the keyword transition would be really handy in the meantime.

[rarila]

I'm in the boat an bring some 🍃, mate.

[SvanteRichter]

Info for anyone that comes along: The version roadmap has changed, and since this issue mentions v3.0 (which is now 4.0) I'm posting this here https://discuss.bolt.cm/d/112-bolt-version-roadmap-changes/7

[SvanteRichter]

@GawainLynch @rarila Is this something that you plan to work on? I'd love to see it fixed, but I'm just worried that a comment from over six months ago is easily forgotten.

[GwendolenLynch]

Plan… yes… time?

[GwendolenLynch]

Well, #6802 seems to have been the "PR that keeps on giving", so sending this to the PR resting place in the digital sky.

@sbonardt this should no longer be a problem for you in 3.3.0+ … if I missed something in what's covered here, please hit the "reopen" button. Hope your weekend was a good one 😉

[sbonardt]

👍 🤘