Hey,
there are some new items on my wishlist:
I would like to be able to change the headline in the panels sidebar. e.g. to change the Title from “Pages” to “Projects”. I think the page’s blueprint would be the best place to declare such a custom title.
I wish there was a reference to the template that is used by the current page’s children. We have some empty space in the list, so why don’t we fill it with this useful information?
byebye,
Tim
The team has discussed this and it sounds easier than it actually is, because it is not just a word in the sidebar but there are other occurrences in the user interface that will be affected by such a change. If you think that in different languages, there is no easy solution. This feature is not going to come in the near future.
That would be a lot easier to implement …
While I totally understand this point, I was wondering if the whole feature is not coming in the near future, why not at least make the pure sidebar titles translatable? Would still bring ease to a lot of developers asking for it and should be quite simple to implement even for multi-language.
The issue is that the modals and other titles would still say “Pages”, which could be pretty confusing for end-users. Our conclusion was that it is better to wait with this feature than to include a temporary feature that isn’t perfect.
Let the developers have the possibilitiy to override the language string with a folder languages-panel in site. Then the developer can call a thing whatever, in whatever language.
The things that are not overwritten can fallback to the correct language default string.
If there is a problem where the word Pages appear in different places, separate them and name them by context.
I think it’s more complicated than that. If you change the labels on a per blueprint basis, you would also have to change the text in a dialog box, e.g. if the user deletes a page. That would have to be different for each blueprint. So you need language strings for all UI occurrences on a per blueprint basis.
I was wondering if it was possible to simplify the language used in order to prevent grammar specifics, but maybe what works in one language may not work in another. An example:
Instead of using “Add a new page”, you could just use “Add page”. In German, this structure would also work (Seite/Beitrag/Projekt hinzufügen) in a way that you could just translate the word without having to consider context. But I don’t know if this would work in all languages.
Yeah, I see the point. Not an easy thing so solve. I guess, your approach to keep the language as generic as possible could work. But just like you, I don’t know each language out there.
However, this custom labeling of the subpages would match quite well to the otherwise flexible features of Kirby.
I absolutely agree that this would be a nice to have feature and @bastianallgeier would love it as well. So there is a change that this will get implemented if someone has a really genius idea how this can be achieved in a great way 
Since this would be attached to a panel content page, couldn’t this feature be a blueprint option? Blueprint labels already have multilanguage capabilities.
Or am I missing something?
This could be a blueprint option but that does not solve the problem with having to exchange not only the text in the sidebar but within the whole UI.
I assume the blueprint is only interpreted when the appropriate template is loaded and not before. Would it be taxing to parse the blueprints within the whole UI?
You mean to put all the UI occurrences with their context into the blueprint? That would be a lot of overhead … Plus: What happens if you have different pages with different blueprints within one folder?
No, what @texnixe is referring to with “whole UI” is, that you not only would need to replace the simple “Files” and “Pages” label in the sidebar. But also you would need to be able to change a lot of modals and all other places where subpages are referred to as (sub-)pages. Cause if you want to name subpages “projects”, this should be reflected in all the modals and all the places that have to deal with these subpages.
It might be possible to change all the English strings that this could work somehow. But since to the different grammar and phrase structure of other languages, this is actually really hard to achieve consistently.
Ah I get it! At first it sounded mostly like a technical limitation. Bad grammar is a pretty good reason.
It makes more sense to me with distantnative’s reply. At first it sounds like an ok idea to have labels in the blueprint, but you’d have to think of every possible permutation of the word you want to use in the languages you want to use, which would be indeed a lot of overhead.
Maybe to make it clearer how many strings are actually affected by changing the term for a subpage:
"pages.show.subpages.title": "Pages",
"pages.show.subpages.empty": "This page has no subpages",
"pages.add.error.max.text": "The maximum number of subpages for the current page has been reached.",
"pages.delete.error.children.text": "This page has subpages and cannot be deleted. Please delete all subpages first.",
"subpages": "Pages",
"subpages.index.headline": "Pages in",
"subpages.index.add": "Add a new page",
"subpages.index.add.first.text": "This page has no subpages yet",
"subpages.index.add.first.button": "Add the first page",
"subpages.index.visible": "Visible pages",
"subpages.index.visible.help": "Drag invisible pages here to sort them/make them visible.",
"subpages.index.invisible": "Invisible pages",
"subpages.index.invisible.help": "Drag visible pages here to unsort them/make them invisible.",
"subpages.add.error": "This page is not allowed to have subpages",
"subpages.add.error.more": "This page cannot have any more subpages",
"subpages.error.missing": "The page could not be found",
Maybe this shows better how difficult it would be to find a good way to let this be defined in a blueprint just for English. And then consider making it work in all languages.
I discussed this already with Lukas and Sonja and it’s indeed horrible. It’s in fact the only reason why this feature is not implemented so far. It’s maybe even one of the best examples of a feature that seems so extermely obvious and easy to add, but as soon as you start thinking about it, it turns into a nightmare. Normally I’d just say: f*** it, it’s not going to work, so let’s forget about it. But I actually want to have it myself. If you believe it or not, I’m sitting on this for at least 1,5 years now. It always keeps on popping up again. Even in my last client project. I was very tempted to get started with the sidebar only, but it just feels wrong.
Actually, what do you think? Would it work to just start with the sidebar? Is it obvious enough for users? Because this would indeed be really easy to implement.
I don’t know if it helps but in WordPress it works like this:
https://codex.wordpress.org/Post_Types
Notice the labels. Double underscores means that it will be translated if translation exists and it find a match to that english string.
Now this is not a blueprint, but in the WordPress world something similar.
add_action( 'init', 'create_post_type' );
function create_post_type() {
register_post_type( 'acme_product',
array(
'labels' => array(
'name' => __( 'Products' ),
'singular_name' => __( 'Product' )
),
'public' => true,
'has_archive' => true,
)
);
}
And here many many more labels.
https://codex.wordpress.org/Function_Reference/register_post_type
add_action( 'init', 'codex_book_init' );
/**
* Register a book post type.
*
* @link http://codex.wordpress.org/Function_Reference/register_post_type
*/
function codex_book_init() {
$labels = array(
'name' => _x( 'Books', 'post type general name', 'your-plugin-textdomain' ),
'singular_name' => _x( 'Book', 'post type singular name', 'your-plugin-textdomain' ),
'menu_name' => _x( 'Books', 'admin menu', 'your-plugin-textdomain' ),
'name_admin_bar' => _x( 'Book', 'add new on admin bar', 'your-plugin-textdomain' ),
'add_new' => _x( 'Add New', 'book', 'your-plugin-textdomain' ),
'add_new_item' => __( 'Add New Book', 'your-plugin-textdomain' ),
'new_item' => __( 'New Book', 'your-plugin-textdomain' ),
'edit_item' => __( 'Edit Book', 'your-plugin-textdomain' ),
'view_item' => __( 'View Book', 'your-plugin-textdomain' ),
'all_items' => __( 'All Books', 'your-plugin-textdomain' ),
'search_items' => __( 'Search Books', 'your-plugin-textdomain' ),
'parent_item_colon' => __( 'Parent Books:', 'your-plugin-textdomain' ),
'not_found' => __( 'No books found.', 'your-plugin-textdomain' ),
'not_found_in_trash' => __( 'No books found in Trash.', 'your-plugin-textdomain' )
);
$args = array(
'labels' => $labels,
'description' => __( 'Description.', 'your-plugin-textdomain' ),
'public' => true,
'publicly_queryable' => true,
'show_ui' => true,
'show_in_menu' => true,
'query_var' => true,
'rewrite' => array( 'slug' => 'book' ),
'capability_type' => 'post',
'has_archive' => true,
'hierarchical' => false,
'menu_position' => null,
'supports' => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' )
);
register_post_type( 'book', $args );
}
Indeed, we can’t always loose the article. In French “Ajouter page” (Add page) is understandable but sound a bit like pidgin. A more correct label would be “Ajouter une page”.
Also word gender in some languages influences spelling, in French again:
“Project added” -> “Projet ajouté” (project is masculine)
“Page added” -> “Page ajoutée” (page is feminine, the adjective gets a final e).
Plurals can also have complex rules (Russian…)
Another way is not using sentences, but instead the object followed with the action as an infinitive verb, like “Page: add”, “Page: ajouter”… But it’s ugly and not always possible.
Yes, and that’s similar in Italian and Spanish; and that’s not thinking about other languages. So we need another solution.
Bastian raised the question above how it would be for the user if the sidebar said “Projects” and if they wanted to delete a project, the dialog box would still ask to “Delete this page?”. Or if there are no projects yet, the line below the label “Project” would contain the information “This page has no subpages”.
