I want to translate some content using placeholder vars inside my vue file for a fanel area. In my understanding the correct helper for this task is $tt (tt() | Kirby CMS) but my vue snippet does not work using $tt(“key”, {“placeholder”:"value}). Instead I need to use
$t(“key”, {placeholder}).
Why is that? - I think I understand fundamentally wrong on how the kirby documentation is supposed to be used…
The Lab states nothing about the $t helper.
I would love to get the following questions answerd - hopefully to understand the documetnation better:
Based on my question above - why do I need $t - the docs state it otherwise - or is this only for templates?
Why does the lab exist? - Until today I never quite understand the use of the lab (https://lab.getkirby.com/public/lab) since there is no code (mostly) - and helpers are not explained correctly (I only now about this site explaining the lab but I clearly overlook something… Maybe I’m not advanced enough yet? - Panel UI | Kirby CMS
Where can I find the documentation for all stuff around plugin development like useable helpers (i.e - $t and $tt for vue or also things like $api and $panel)?
I try to understand the correct useage of kirby but I thin currently is a big understanding on my side on how to utilize the kirby documentation (or is the documentation just not complete?)
I think there are indeed some things mixed up, but I also can understand why that happens:
The tt() helper docs you linked are about the PHP helper function. Not anything in relation to frontend/Vue Panel code. This might be confusing because in Vue we have a helper this.$t() (or just $t inside the template section) that function similar to the PHP backend helper function t() - but these aren’t the same. Which is why, as you found out, our Vue $t() helper does directly support passing data to replace template strings.
In general, I think it is a very fair depiction that Kirby’s backend/PHP docs are a lot more mature than our documentation for the Panel/Vue part. The latter still has many gaps unfortunately. The Lab is an attempt at closing this. To give some background: Before the lab, we tried to document all our Vue components, helpers etc. in the Kirby docs manually. This was quite the failure as they kept getting outdated and our capacities and maintaining, but even more at extending them were too small. On the backend side, we already had the advantage that a lot of the docs get automatically generated by reflecting the actual Kirby core code. With the Lab, we started a first step to have this for the Panel/frontend code as well. The Lab serves two purposes: It is where we ind development create many example setups for testing, but it also generates docs from the code directly. so the Lab currently is the place where you find documentation for Panel development for Kirby. Again, admittedly not complete - the $t() helper is missing indeed. But in the Lab you can find things you asked for:
In the “Components” section on https://lab.getkirby.com/public/lab you can find examples of how the components can be used. In many of these you can toggle between the preview and the code:
So I would say it’s somewhere in the middle: It’s not that there is nothing existent or false, but it might be sometimes not easy to understand the difference between PHP code docs and Panel (UI) docs, also cause they live in slightly different places. And there is still stuff missing from the Lab, but we hope to build on it further and further until we hopefully reach the same level as the backend docs.
first of all - thank you for your and the teams great work. I really love to work with kirby and I’ve built all my sites in the last 3 years only with it. The PHP documentation is indeed very good and this forum - especially Sonja is amazing ^^
That said these are my first steps in the plugin field - please forgive me my maybe slightly stupid questions but the api link you sent is one of the things I dont understand - e.g - the documentation for the Post part shows the following:
There is no example (I think since it is no component?) - but there is also no way to see what each parameter can do and until now I found no simple way to find the functions inside the kirby repo to check it out for myself (and if I found something it was mostly not understandable for me since there are often dependencies between different parts of kirby ^^)
Is there a simple way to “find the answers I need” that I simply don’t see?
Another thing is the components itself - I often find it somewhat difficult to understand the code examples - e.g I had a difficult time understanding I need to use k-input-field for textinputs and not k-input - but the documentation shows a normal input field: https://lab.getkirby.com/public/lab/components/input.
I am often unsure if the cause is that I am not vue native and dont understand all things (yet) or if I use the documentation (lab) simply wrong ^^
Totally fair point, the API docs there so far simply state what methods exists and the names of the parameters. But no detailed info. That’s not great indeed.
Working on the Panel, it can be really beneficial to be familiar with Vue - especially because sooner or later you probably will end up looking into our core code as well, cause you easily hit the wall in certain areas of those docs.
While the PHP backend code has matured over many years and in most parts is quite stable even between major releases of Kirby, our Panel is much younger and has evolved a lot more between Kirby 3, 4 and 5. And that’s also why the docs here aren’t as great as for the PHP part. It’s a little bit the dilemma that we have opened the Panel up for developers so much to customize it, extend it etc. - but without having been able to document it all detailed and also with setups that we created for our own initially (e.g. <k-input type=="text"> vs. <k-text-input>) because they helped us achieve something or also because we were worse Vue developers than now ourselves. But those setups often do not make the most sense when opening it for plugin developers to use. Yet still we did not want to lock down the Panel for plugin developers to only very restricted parts we fully documented. This is what leaves us currently into this dilemma that the Panel is so extensible and customizable, but many parts aren’t fully documented, some parts are rather crude and thus hard to explain to plugin developers etc.
I am not saying this all to defend it, but maybe to better understand the current state.
- e.g - the documentation for the Post part shows the following: