deprecate validation that a resource localization exists in the default language

[tomerd]

motivation: the warning is redundant

changes:

• remove the validation when english is the default langauge
• adjust test
• refactor TargetSourcesBuilderTests so we can test for no diagnostics

rdar://86297221

[tomerd]

@swift-ci please smoke test

[SDGGiesbrecht]

Please explain; the warning does not look redundant to me.

[abertelrud]

Is this tied to English, though? If I've specified that my package's default localization is, say, Icelandic, instead of English, then it's the Icelandic translation that doesn't have to be provided as .strings files.

[abertelrud]

Although now that raises the question to me of what SwiftPM does with that default localization specified in the package, so I don't know how a non-English default localization would actually be conveyed to Foundation at runtime.

[SDGGiesbrecht]

I don't know how a non-English default localization would actually be conveyed to Foundation at runtime.

It is CFBundleDevelopmentRegion in Info.plist, which SwiftPM handles properly (last I checked at least).

it's the Icelandic translation that doesn't have to be provided as .strings files

But I am pretty sure you should always have a .strings file, even if all keys and values happen to match exactly. If there is nothing to force the presence of a directory for that localization, you have lost the standard indicator of what localizations are supported. I do not remember if Foundation bothers to union in CFBundleDevelopmentRegion, or just assumes you were smart enough not to leave it out. CFBundleLocalizations can be used to override what is determined from the directory structure, but when I search for it in the SwiftPM repository, there are no hits.

It is also generally unsafe to assume that keys will match the development localization’s values. Some times it is not even possible to select keys that way, because in the development language, two things may happen to have the same label, but need to differ in other localizations. A concrete example would be in TextEdit under Format → Font, where both Ligatures and Kern have a “Use None” option. Both labels are “Use None” in English, but in French one is « Aucun » while the other is « Aucune ».

[tomerd]

this PR is an attempt to address a reportedly redundant warning SwiftPM now presents. the original issue this is trying to fix states:

It’s reasonable for a localizable resource to not exist in en.lproj, but exist in a target language .lproj. In fact, this is what we recommend developers do for localized strings when using Xcode.

For example, I can have the following string defined as English in code:

NSLocalizedString(“Hello!”, comment: “A friendly greeting.”)

Because the string key is already in English, I do not need to have an en.lproj/Localizable.strings file in my project and Foundation will automatically pick up “Hello!” directly from the code.

I am not very familiar with how this system works, so this fix may be incorrect. @abertelrud @neonichu any advise on how to more correctly fix this?

[SDGGiesbrecht]

Because the string key is already in English, I do not need to have an en.lproj/Localizable.strings file in my project and Foundation will automatically pick up “Hello!” directly from the code.

This comment is not generally true. It is only true in the particular example because two other facts happen to be true:

1. In the line NSLocalizedString("Hello!", comment: “A friendly greeting.”), the string "Hello!" happens to actually be human‐readable English. In another case it might instead be "HELLO_(ONE_ADDRESSEE)" (for Hello!/Γεια σου!) or "HELLO_(SEVERAL_ADDRESSEES)" (for Hello!/Γεια σας!). There is no way for the compiler to check whether the key actually is human‐readable.
2. Either CFBundleLocalizations in the Info.plist includes en, or some other file is separately ensuring the existence of an en.lproj directory (e.g. InfoPlist.strings).

In fact, this is what we recommend developers do for localized strings when using Xcode.

I have always recommended the opposite, precisely because it relies on far‐flung conditions holding true, which few developers understand very well, let alone remember. In my opinion it is the documentation you quote which needs fixing instead.

---

This section of code is not just used by .strings though. Doesn’t it apply to all kinds of resources?

There are basically two philosophies SwiftPM can choose from:

• Assume every resource will usually be localized into every localization, and that if something is missing, it is most likely a mistake. Defaults and placeholders must be explicitly copied into the localization to indicate that they are not being used by mistake. (For .strings files, this means generating an unmodified .strings file.) This is the status quo, so in this case the fix is to do nothing, except possibly add more information to the warning description.

  • (A modification of this would be to make the warnings explicitly suppressible in the manifest somehow, but I doubt it is worth the effort.)

• Assume some resources will often be left out of some localizations, and that if .lproj directories have varying contents, it is intentional. Users must use separate tooling to validate the completeness of the localizations. In this case the fix is to remove diagnoseMissingDevelopmentRegionResource entirely, along with diagnoseLocalizedAndUnlocalizedVariants, which overreaches in the same way.

Whether or not files should be duplicated is not unique to the development localization anyway. If you develop for es but also have both an en and an en_US, you may just want the en_US to fall back for everything but some measurement‐related bits.

[SDGGiesbrecht]

There is no requirement to have any strings files for the development localization if the content in the source code is sufficient

That is true of all localizations, not just the development one.

---

The longer I think about it, the more I talk myself out of the first option in favour of the second. Just remove diagnoseMissingDevelopmentRegionResource entirely.

If users submit requests to have this sort of validation restored, then to support it properly, we would need to modify the Localization enumeration to better the communicate the intent. Examples might be .requiredByAll, .requiredByAllButDefault, .optional, .requiredByRightToLeft or whatever else turns out to be useful.

[tomerd]

sounds good to me. @neonichu @abertelrud?

[abertelrud]

I agree, that makes sense to me.

[tomerd]

PR updated to remove it altogether

[abertelrud]

Saw that, looks good.

[tomerd]

@swift-ci please smoke test