[conditional-rendering] Make object data easier for translation

[rammba]

While translating conditional-rendering page I encountered one small issue. Namely, last (3rd) challenge solution has list of objects in the code which are referenced by its names. Name of the object is not the property of the object, so I needed to make workaround. Since I'm trying to translate all the text, including object property values, I needed to introduce name field to the object, similar to the example at the end of thinking-in-react page:

const PRODUCTS = [
  {category: "Fruits", price: "$1", stocked: true, name: "Apple"},
  {category: "Fruits", price: "$1", stocked: true, name: "Dragonfruit"},
  {category: "Fruits", price: "$2", stocked: false, name: "Passionfruit"},
  {category: "Vegetables", price: "$2", stocked: true, name: "Spinach"},
  {category: "Vegetables", price: "$4", stocked: false, name: "Pumpkin"},
  {category: "Vegetables", price: "$1", stocked: true, name: "Peas"}
];

I saw that some other languages also have similar workaround: French:

Spanish:

I didn't want to use either english names as in the french solution nor non-english names of variables as in the spanish solution. My idea was to have all functions/variables/etc. in english and all object values on my mother tongue, Serbian. I've made this PR based on the changes in Serbian repository: https://github.com/reactjs/sr.react.dev/pull/99

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
19-react-dev	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 18, 2024 5:57pm
react-dev	✅ Ready (Inspect)	Visit Preview		Nov 18, 2024 5:57pm

[github-actions[bot]]

Size changes

📦 Next.js Bundle Analysis for react-dev

This analysis was generated by the Next.js Bundle Analysis action. 🤖

This PR introduced no changes to the JavaScript bundle! 🙌

[rammba]

Hey @gaearon @rickhanlonii @eps1lon, can you please take a look?

[rammba]

On many places object data are used within the code, but on other places it's possible to translate object content, which is not the case here.

[rickhanlonii]

What's wrong with the French language solution, isn't this how you would write it if you were writing it yourself? Using a normalized data structure is better here if possible since you don't need the slower find lookup.

[rammba]

Hey @rickhanlonii, thanks for clarifying this topic. I didn't think about speed difference between find() and direct access by the key. If you agree I can incorporate French's solution here?

[rickhanlonii]

Yeah please do, and that means we can close this?

[rammba]

Hey @rickhanlonii, I've incorporated French's solution here.

[rickhanlonii]

Ok sorry, I said the French version but I meant the Spanish version. For native speakers, wouldn't you want to write:

<Drink name="name-in-your-language" />

Not

<Drink name="tea" />

Since tea is in english? Is there a blocker to this do to characters or something?

[rammba]

Hello @rickhanlonii, As I said in the description: I didn't want to use non-english names of variables as in the spanish solution. For me it looks ugly to name variables with non-ASCII characters, while it's totally fine to have object data with those characters. But, if you prefer that way, I will do that.