Not working
Closed this issue · 7 comments
Something seems to be wrong with the plugin. If I set up a basic example as in the instructions, when I edit the second language the text is not saved and reverts back to the primary language value.
Hello, I'll check the plugin against latest Kirby versions and let you know if I find something.
Kirby updated : it kind of works on my side, although there seems to be some weird behaviours since v0.1.2, probably related to blueprint fieldsets parsing.
Try v0.1.1 for now or try adding extends: fields/translatedlayoutwithfieldsets to your field (as in the readme).
Hi, I've done a bit of extensive testing with this plugin, and I can't really work out what is going on because the block content does not actually get synced, only the visual representation in the editor. If you add blocks in the default language, then they will appear in the second language. If you remove a block from the default language, that block will not appear in the second language, but it will still be there in the layout in the .txt file for the content of that page. The content is not actually getting saved anywhere, it seems like only arrays in php are being manipulated. Also if you delete a layout from the default language, again the translation remains in the .txt file. I'd be interested in trying to get this to work as I see the need for it.
Hello,
Indeed there seems to be something wrong... it used to work on my dev sandbox in a fresh starterkit when I published it. Probably a breaking Kirby update or some hardcoded local kirby changes I thought to be useless, still being needed.
Sorry for the late answers, I have very few time to look into this now or give directions. Try reading the comments in the source code which more or less explain my findings. The implementation is a bit hacky and reproduces quite a lot of Kirby behaviour with minor changes when the APIs are too restricted or hardcoded (https://github.com/getkirby/kirby/issues/3961).
In short, the default language is always loaded as a content-structure-model, then it's merged with the translation (if the same UUID exists). The core logic happens in the Field::Fill function, and it's also where it gets more complicated, as the fill function is often called multiple times for different purposes (update/save/validate/display/etc.).
One other thing I can think of is this modification that I made to my installation while developing this, so that the panel shows modifications without reloading the page : https://github.com/getkirby/kirby/issues/3972. (ajax issue)
There's also some weird Kirby behaviour described here which might be involved : https://github.com/getkirby/kirby/issues/4110
if you delete a layout from the default language, again the translation remains in the .txt file
That feature has to be implemented, I haven't done any deletion tests.
Hey, I think the plugin broke in 3.7 or 3.8, it should work again now with some new features.
I just tested it in a fresh starterkit. :)
Please let me know if you're still having issues.
Hi,
Yes it works! Was there a clear reason for the problem? I would like to use the plugin on a production site but I'm a bit wary of data loss (I know the plugin is beta, but it's so useful!).
Ok, glad that it works too.
I'm starting to heavily implement it on my local dev environment while I plan to use it on production in the future, but I can't guarantee anything on how well it works, it's up to you to decide. This said, I can give some insights / thoughts:
- I have a better understanding of how Kirby fields work in general compared to when I started this plugin and I'm really happy with how it works now. While it relies on some "custom code", it's very minimal and it's quite unlikely to break :
- The default language should never break nor risk data loss, except if Kirby's layout-field-related vue component templates change, and you can fix it yourself by rebuilding with the updated Kirby.
- The translations rely on the "custom code" which is just loading+parsing both langs from content (using native functions), placing
idas array keys and replace translateable IDs, ignoreing anything else, then removing the id-array-keys. - The custom panel components are UI-only changes, it would even work with the native layout-field-component.
- On the performance side, there are surely some things to optimize, but note that :
- The (native) layout field is heavier then other "simple" Kirby fields in the way that it needs to parse blueprints to retrieve values from the frontend (template code). This is exactly where the "minimal code" interacts, so loading both the translation AND the default language content, which theoretically doubles the parse time. On the other side, it's also the native Kirby way of handling translations, if I'm correct, so on that side there should be no performance hit comparatively.
- I can't guess of a better way as this is a requirement for translateing with replacements, I guess this is how any other translations work on any multilangage Kirby site. There's the k3-categories way where it listens for linked translation changes for updating the translation-content-file with default-language-value of non-translateable fields, then you can read only 1 translation file on the template side, but that doesn't match the Kirby translation logics and requires way more code and user-configuration)
- Another hitch I could think of in the near future is parameters/options, but that's a question of testing, using, discussing, and eventually implementing some more functionality. Thus the beta phase. (eg: What happens when the translation is empty but set ? Is there a way to translate block-fields with inner fieldsets [structurefield in a block, ...] ? Can kirby suddenly change de UUID of a block ? What happens when blocks are converted to another type ? )
- I understand the usefulness of the plugin and that's also why I initiated it, we're probably not alone. I'm kind of surprised Kirby has never brought better multi-language support on their most interesting and useful fields. They kind of state that translations are "handled"/"supported", and that handling it "better" is intended in the future but requires some heavy internal refactoring and it's on their internal refactoring list (which must be huge), no idea when they plan to get on it.
- On the other side, the Kirby-team recently announced that they are very happy with the blocks/layouts implementation, that it's very robust and they plan to extend it further into the core. My only fear is on how that will handle translation in this process and how that will eventually break (or rather facilitate?) this plugin.
The bug... I haven't investigated deeply, but it seems related to Kirby introducing UUIDs on blocks, columns and layouts, breaking the keysToIndexes functions.