IRC logs for #farmOS, 2023-01-17 (GMT)

2023-01-16
2023-01-18
TimeNickMessage
[07:16:31]<FarmerEd[m]>mstenta: should untranslatable content have `"langcode : en"` at all?
[07:17:31]<FarmerEd[m]>`"langcode : und"` and `"langcode : zxx"` both work for patching in all languages
[07:17:54]<FarmerEd[m]>und = Not Specified
[07:17:54]<FarmerEd[m]>zxx = Not Applicable
[07:18:46]<FarmerEd[m]>but the original log needs to have und or zxx set before trying to patch with the API
[10:46:31]<mstenta[m]>Farmer Ed: good question!
[10:47:01]<mstenta[m]>i don't know enough about the localization subsystems to know what's "right"
[10:48:13]<mstenta[m]>> `"langcode : und"` and `"langcode : zxx"` both work for patching in all languages
[10:48:26]<mstenta[m]>this is really good to know!
[10:48:41]<mstenta[m]>i wonder what currently determines the default language that gets set when new entities are created
[10:49:16]<mstenta[m]>i imagine Drupal just uses the default language of the site... but i wonder if there is a "recommended" way to say "always use und"
[10:49:33]<mstenta[m]>or if that would be considered a "hack" as well
[10:50:55]<mstenta[m]>i'd like to understand the proper way to do things before we make any code changes... although based on that d.o issue there may not be a "proper" way persay
[10:52:03]<FarmerEd[m]>ACTION uploaded an image: (13KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/GfFlVPpKdez... >
[10:52:25]<FarmerEd[m]>It can be set in the UI anyway
[10:52:52]<mstenta[m]>ah ok... which i imagine means it can also be set in yml on a per-type basis
[10:53:20]<mstenta[m]>this feels like something we should bring to the experts in Drupal Slack #multilingual :-)
[10:54:34]<FarmerEd[m]>Can't say I was aware of those #experts, but sounds like the right group 😄
[10:56:01]<mstenta[m]>i know just enough about the ins-and-outs of drupal's localization systems not to trust any quick fixes 😅
[10:56:24]<mstenta[m]>but maybe that's all we'd need to do!
[10:57:23]<FarmerEd[m]>I know you said farmOS does not support content translation but did you set something to prevent content language change via the API?
[10:57:38]<mstenta[m]>i don't think i did
[10:58:37]<mstenta[m]>basically all of the "decisions" we've made (or haven't made) are encapsulated in this module: https://github.com/farmOS/farmOS/tree/2.x/modules/core/l10n
[11:00:21]<FarmerEd[m]>When langcode is set to undefined or not applicable, you can set it via the API but once it is set to a language you cannot. It says not allowed to change langcode
[11:00:31]<mstenta[m]>there is code to prevent changing the DEFAULT language of the site
[11:00:48]<mstenta[m]>because of the issue we discovered... described in that d.o link i posted in the forum topic
[11:00:53]<FarmerEd[m]>But this is just of that entity
[11:01:02]<mstenta[m]>but default languages of each entity aren't touched
[11:01:48]<mstenta[m]>i do like the idea of just making the default language "undefined" for all farmOS entities
[11:02:09]<FarmerEd[m]>Also changing langcode to the langcode of the user allows patching
[11:03:32]<mstenta[m]>although changing all of them everywhere isn't exactly simple... we would have to change all the YML configs, make sure that gets reverted everywhere, add an update hook to change all EXISTING entities to und... and then there's also contrib modules that add their own types
[11:03:42]<FarmerEd[m]>I was wondering about the existing logs if we do that. But maybe there is not that many foreign language users using API functions.
[11:04:01]<mstenta[m]>so i would want to be very confident that this won't break anything else
[11:04:02]<FarmerEd[m]>👍
[11:04:27]<mstenta[m]>i also wonder about that if statement that causes the error in the first place...
[11:04:42]<mstenta[m]>it seems like it was recently tweaked in core to fix another issue... maybe it's just still not perfect
[11:05:24]<mstenta[m]>but i think that gets back to the bigger question that seems to "active" in drupal.org about how all this stuff *should* work
[11:05:58]<mstenta[m]>it seems to me that in Pat's case, updating a log that has a langcode of en should be allowed, even though his user's default language is nb
[11:07:05]<mstenta[m]>i can understand preventing that if you are working with content translations... but if you're not?
[11:07:06]<mstenta[m]>and even with content translations... shouldn't a user be able to use multiple languages? who cares what his default is?? shouldn't he be able to update anything he wants?
[11:07:21]<mstenta[m]>so i still have some deeper questions :-)
[11:08:01]<mstenta[m]>one aspect to this that i didn't go into detail about in the forum topic is: "language negotiation"
[11:08:11]<mstenta[m]>that's basically the way that drupal is configured to decide "which language to use"
[11:08:40]<mstenta[m]>and we have some control over that... we explicitly set that configuration via the farm_l10n module
[11:09:07]<mstenta[m]>it's basically a way of configuring the order of preference for which language is used
[11:09:35]<mstenta[m]>https://github.com/farmOS/farmOS/blob/b99f46cce429f0fd152b32a8d1ae76a1cf...
[11:10:17]<mstenta[m]>our config is basically: "if the user has a default language, use that. otherwise use the site default"
[11:10:54]<mstenta[m]>i think that's what's setting nb in the code that ultimately throws the error
[11:11:06]<symbioquine[m]>Yeah, I'm not quite sure how well the default CMS/site-builder oriented language logic will map to farmOS...
[11:11:08]<mstenta[m]>so maybe there's an opportunity to change it there too
[11:11:37]<symbioquine[m]>The interface translation stuff seems like the easy part
[11:11:43]<mstenta[m]>symbioquine: exactly... we have slightly different requirements
[11:12:01]<symbioquine[m]>* like the "easy, * easy" part
[11:12:27]<mstenta[m]>and i assume a lot of the logic in drupal core has focused more on the content translation side of things
[11:12:37]<mstenta[m]>so we are bringing more of the interface voice :-)
[14:02:09]<mstenta[m]>@penyaskito in Drupal slack seems to suggest it's a core bug:
[14:02:09]<mstenta[m]>> I would need to debug this, but `nb` should be the INTERFACE language, but if content is all `en` not the CONTENT language. So I guess that's definitely a bug and not an issue in your config
[14:05:08]<FarmerEd[m]>But is it a core issue that's been bounced around for years?
[14:06:36]<mstenta[m]>Oh no doubt
[14:06:40]<mstenta[m]>lol
[14:06:58]<mstenta[m]>Better question: are any core issues NOT bounced around for years? 😆
[14:07:27]<mstenta[m]>Just joking... it sounds like this might be one that is newly discovered by us perhaps
[14:32:01]<FarmerEd[m]>Who found that can of worms...🤣
[14:32:34]<mstenta[m]>Credit where credit is due postmanpat
[14:33:07]<mstenta[m]>Getting some really good info and ideas/recommendations from @penyaskito...
[14:33:16]<FarmerEd[m]>Well he certainly has a knack for them anyway
[14:33:21]<mstenta[m]>I'll copy the chat into the forum when it's concluded
[14:45:57]<FarmerEd[m]>Well, he's not wrong, enabling content translations does work
[14:48:18]<mstenta[m]>ah you're following along! haha
[14:48:27]<mstenta[m]>i think we may have a good solution to try!
[14:48:55]<mstenta[m]>hook_entity_bundle_info_alter
[14:55:18]<FarmerEd[m]><mstenta[m]> "ah you're following along! haha" <- I thought you'd figured that out already 😁
[14:56:53]<mstenta[m]>bah there's no way to get a slack chat transcript???
[14:56:54]<mstenta[m]>slack is utterly useless
[14:58:25]<mstenta[m]>Farmer Ed: do you still have a testing env set up?
[14:58:41]<mstenta[m]>if i sketch up a bit of code would it be easy to try it out?
[14:59:56]<FarmerEd[m]>yes, assuming un-installing content translations breaks it again
[15:00:20]<mstenta[m]>oh yes do that first :-)
[15:06:44]<mstenta[m]>ah i gotta run and pick up the kids...
[15:07:01]<mstenta[m]>this is what i would have you try... in `farm_l10n.module`:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/64d6498735...)
[15:07:12]<mstenta[m]>(assuming you are testing with a lab_test log... adjust accordingly if not)
[15:07:17]<mstenta[m]>back later!
[15:17:16]<FarmerEd[m]>it works!!!!
[15:19:16]<mstenta[m]>Wow awesome!
[15:20:07]<mstenta[m]>So we basically just need to do that for all entity types+bundles
[15:20:16]<mstenta[m]>But also wrap it in a condition so that it only runs if the content translation module is not installed
[15:20:31]<mstenta[m]>(And copious comments to explain why)
[15:20:46]<FarmerEd[m]>cool
[15:21:48]<FarmerEd[m]>Do they all need to be specified individually?
[15:22:17]<FarmerEd[m]>or just types?
[15:23:08]<mstenta[m]>I think a foreach would do :-)
[15:23:25]<mstenta[m]>Question is: should we do it for ALL entity types?
[15:23:38]<mstenta[m]>I imagine it would be OK to?
[15:24:35]<mstenta[m]>> But also wrap it in a condition so that it only runs if the content translation module is not installed
[15:24:35]<mstenta[m]>As long as this condition is there, theres an escape hatch for anyone that actually needs it
[15:25:45]<FarmerEd[m]>And anyone who needs it has no issue as long as this code is not applied
[15:26:16]<mstenta[m]>Exactly. Thats what it sounds like
[15:27:01]<FarmerEd[m]>mstenta[m]: Don't we need to, all entities should be modifiable via the API
[15:27:55]<mstenta[m]>Yea I don't see any reason not to
[15:28:21]<mstenta[m]>I didnt look closely at what other entity types were included before I left
[15:28:46]<mstenta[m]>But that hook should only include content entities with bundles
[15:29:17]<mstenta[m]>So I think its safe
[16:19:40]* wildhavenfarm[m] has joined #farmos