Tuist generates TuistStrings+Module from wrong localization strings file

[bozongiggsa]

Describe the bug and the expected behavior

If project contains several languages with different regions, ex. en, en-GB, en-NG and "ru" is set as Development Language through Options in Project, then Tuist gets en-GB.lproj/Localizable.strings as a source for generation of TuistStrings+Module file. But I expect that ru.lproj/Localizable.strings would be used as a source for keys when Tuist are generating TuistStrings+Module

Reproduction steps

Steps to reproduce the bug:

1. Add Localizable.strings for framework Module and add several languages for it. For instance: en, en-GB, fi, de
2. Set "de" as a Development Language. The main thing that it should differs from "en", "en-GB"
3. Make "tuist generate"
4. Look at TuistStrings+Module.swift file.

Results: keys in TuistStrings+Module.swift are generated from en-GB.lproj/Localizable.strings file
Expected: keys are generated from de.lproj/Localizable.strings.

Error screenshots

Additional context

• macOS version: 12.4
• Tuist version: 3.5.0
• Xcode version: 13.3.1 (13E500a)

Add any other context about the problem here.

[fortmarek]

Hey @bozongiggsa 👋

You can find the file used for generating these accessors here. That being said, shouldn't the keys be the same regardless of your current development language? That's the point of keys, they stay the same across the languages 🤔

[danieleformichelli]

Hey @bozongiggsa 👋

You can find the file used for generating these accessors here. That being said, shouldn't the keys be the same regardless of your current development language? That's the point of keys, they stay the same across the languages 🤔

I think they might be different in case you have some strings not localized in all locales, for example for experiments or features available only in some specific languages/regions

[AllDmeat]

That being said, shouldn't the keys be the same regardless of your current development language?

Yes, but no.
In our app we support over 13 languages, and that for today. In a few month we may have more.
During new features development we're adding keys for development language only, because we simply don't know all other supported languages.
But translators do know. We've integrated translation service — it ships all news keys from development language to translators, they translate, and we receive the result back. That is the time when key with it's translated string is added into the project for the specific language by translation service. Until that time some languages may have not all supported keys. Expect for development language, because it's, well, a development language.

[github-actions]

Hola 👋,

We want to inform you that the issue has been marked as stale. This means that there hasn't been any activity or updates on it for quite some time, and it's possible that it may no longer be relevant or actionable.
If you still believe that this issue is valid and requires attention, please provide an update or any additional information that can help us address it. Otherwise, we may consider closing it in the near future.
Thank you for your understanding.

[danieleformichelli]

Hi @bozongiggsa @AllDmeat , if you'd like to contribute to the feature, feel free to start from the pointer that Marek lined above, and if you have any question feel free to ask 🙏

[leszko11]

Hey there 👋
I did some debugging and I think the only thing to have it working is setting defaultKnownRegions in project options
If defaultKnownRegions is not set, SynthesizedResourceInterfaceProjectMapper uses ["Base", "en"] as default, and then returns first resource path - ["Base", "en"] if exist

Is there any reason to have ["Base", "en"] as default? Without default value, SynthesizedResourceInterfaceProjectMapper will respect developmentRegion project option

[fortmarek]

Hey 👋

Nice find! Can we rewrite the line, so it takes the region for defaultKnownRegions from the developmentRegion instead?

[leszko11]

Yes,

I think default values in var regionPriorityQueue = defaultKnownRegions ?? ["Base", "en"] are not needed, because developmentRegion is used in the next line.
Without ["Base", "en"] it will use:

• developmentRegion language if set, and exists in localizables list
• first language from the languages list

[fortmarek]

Makes sense, would you be up to implement this change? 😇

[leszko11]

On it 🫡