Untranslated strings in Lab_test log form and Birth_log form

Sorry @aathi179 and @Sourav_Paul but I can't reproduce this on a fresh installation of farmOS. I can see all of the strings you mentioned as translatable in admin/config/regional/translate.

However, I may have a clue as to what's happening... Are you experiencing it on an existing installation? Can you test it on a fresh installation as well to see if it works there?

These strings actually come from two different places. For new installations, they come from these config entities:

https://github.com/farmOS/farmOS/blob/3.x/modules/log/birth/config/insta...

https://github.com/farmOS/farmOS/blob/3.x/modules/log/lab_test/config/in...

Those are "base field override" configuration entities, which are used to override base field configurations. For more background, see https://www.previousnext.com.au/blog/overriding-base-field-labels-and-de...

However, config entities provided in a module's config/install directory are only installed when the module is installed for the first time. So, when we added those config entities in farmOS core, we also needed to provide update hooks to create them on existing sites. That is what the two hook_post_update_NAME() implementations that you pointed to are for.

Strings that are part of configuration entity YML files do not need to be wrapped in t() functions to make them translatable. The Drupal core config_translation module makes all config entities translatable. But, perhaps we do need to wrap them in t() when we create configuration entities in update hooks.

If so, then your MR makes sense, but it would not solve the problem for users of existing sites who have already run those update hooks. So it is not a complete fix. I think the only way to do it would be to create a second update hook (in both modules) which loads the config entity, changes the string to be translatable, and then saves them again.

However, we need to be careful. If the user has already overridden the strings we don't want to throw away their overrides. This is probably unlikely, but it is our responsibility not to break things for downstream users. So the new update hooks would need to check to make sure that the entities are using the default strings before making any changes to them.

All of this assumes that my hunch is correct, and that this issue is only happening on existing sites that ran those update hooks. That needs to be confirmed first.

It's up to you if you want to dig further into this. But it may be easier to just fix the issue in your own instance manually. We can rest assured that new installations of farmOS will not be affected by this issue.