Hi,

Thanks for the detailed analysis and the workaround you've already implemented. This is a valid use case — large modules can end up with hundreds of localization keys in a single file, and splitting by entity/feature is a reasonable way to keep things maintainable.

We're open to accepting a PR for this. A few things to keep in mind:

1. Merge strategy for duplicate keys: When the same key exists in multiple files for the same culture, the behavior should be clearly defined. We suggest the last loaded file wins (later file overrides earlier), but please make this clear in the code with a comment.

2. File loading order: The merge result depends on the order files are loaded. Currently, files are iterated via IVirtualFileProvider.GetDirectoryContents(), which follows the filesystem order. This should be documented so users know what to expect.

3. StaticLocalizationDictionary changes: Instead of rebuilding the dictionary using a temporary Dictionary<string, LocalizedString> in CreateDictionaries(), consider adding a Merge method to StaticLocalizationDictionary to make the intent explicit and the code cleaner.

4. Tests: Please add unit tests covering the multi-file merge scenario, including the duplicate key case.

Feel free to open a PR — we'll review it.

Thanks

@maliming thanks for inputs. About point 1, I don't think we need to change current behavior. Having same keys is not something that should be the case, and throw the error like it now is fine:

Hi,

Good point — I agree. Keeping the exception for duplicate keys across files is the safer approach. The purpose of splitting files is organizing keys, not overriding them. Throwing an error when the same key appears in multiple files will help users catch unintentional duplicates early.

Looking forward to your PR.

Thanks

@maliming I'm thinking about this check:

and can't find any case then this check will make sense.

• When texts are simple strings last value always win, this is how default serialization works
• When texts are json object it will have same behavior thanks to

  abp/framework/src/Volo.Abp.Localization/Volo/Abp/Localization/Json/JsonLocalizationDictionaryBuilder.cs

  Line 99 in c08dbb0

  result[item.Key] = item.Value;

Sample for second case:

       var input = @"{
""culture"": ""en"",
""texts"": {
   ""ThisFieldIsRequired"": ""This field is required"",
   ""DeepLocaliaztionKey"": {""DeepKey"": ""DeepValue""},
   ""DeepLocaliaztionKey__DeepKey"": ""Another translation""
}
}";

       var localizationDictionary = JsonLocalizationDictionaryBuilder.BuildFromJsonString(input);
       localizationDictionary.ShouldNotBeNull();
       var localizationString = localizationDictionary.GetOrNull("DeepLocaliaztionKey__DeepKey");
       localizationString.ShouldNotBeNull();
       localizationString.Value.ShouldBe("Another translation");

Do you know why this check was added?

Actully, this even can't be the case because of nature of the FlattenTexts - it return Dictionary<string, string>, so can't have same keys.

Hi,

You are right — this check is likely a leftover from earlier JSON library behavior that may have handled duplicate keys differently. It is effectively dead code now.

Feel free to keep it or remove it in your PR — it is not a big deal either way.

Thanks