LF-3787 The common name for a crop should be displayed on the Crop Detailed page once changes are made

[den4ik1203]

…are made

Description

The common name for a crop should be displayed on the Crop Detailed page once changes are made

Jira link: https://lite-farm.atlassian.net/browse/LF-3787

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Passes test case
• UI components visually reviewed on desktop view
• UI components visually reviewed on mobile view
• Other (please explain)

Checklist:

• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• The precommit and linting ran successfully
• I have added or updated language tags for text that's part of the UI
• I have added "MISSING" for all new language tags to languages I don't speak
• I have added the GNU General Public License to all new files

[kathyavini]

This is a very interesting little UX issue which I didn't know about until taking a look at this ticket, thanks @den4ik1203!

It looks like there is some fundamental UX confusion in these forms, because the Jira ticket description and the linked bug both describe "editing the crop common name" when the form item in question is actually the crop variety common name.

I'm therefore not sure the right answer is showing the crop variety in the header (the use of the scientific name -- and also the name "Crop Header" for this component makes me think it was meant to stay fixed at crop) -- but I think we can take this to dev-design tomorrow; it will be an interesting discussion point there.

[kathyavini]

This definitely works to implement the Jira-described solution! 👍

However, it's just slightly misleading. What it is doing, is calling the translation function t() and saying "look for the translation in the crop file that corresponds to the key {{crop_variety_name}}". Crop variety name is going to be a user-input string (or by default, a translated string corresponding to the crop key) so it definitely doesn't exist as a key in that file.

Instead, I recommend using here {crop_variety_name} directly, without the call to i18n.

Since i18n will anyway default to displaying the key if it doesn't exist, the end result in the UI will be the same, but it's clearer because it's not suggesting that we have a translation for crop:${crop_variety_name} when we don't.