False "Missing messages from template" warning for locale inheritance in ARB files

[radomir9720]

Description

When working with ARB files for localization, it is common to have a base locale file (e.g., app_en.arb) and region-specific files (e.g., app_en_us.arb). The region-specific file is expected to inherit messages from the base locale if a key is missing.

However, the extension currently shows a "Missing messages from template" warning for keys that are intentionally inherited from the base locale file. This warning is misleading, since the missing messages will be correctly delegated from the base locale during code generation.

Expected behavior

The extension should recognize locale inheritance (e.g., en_us inheriting from en) and suppress "missing messages" warnings for keys that are present in the base locale file.

Actual behavior

The extension reports missing messages even though they are inherited from the base locale.

Steps to reproduce

1. Create a base locale ARB file (e.g., app_en.arb) with some messages.
2. Create a region-specific ARB file (e.g., app_en_us.arb) without duplicating inherited messages.
3. Observe the "Missing messages from template" warning.

Suggested solution

Update the extension to detect locale inheritance based on file naming conventions and suppress missing message warnings for inherited

[mosuem]

Does setting the @@x-template key help? I think the extension doesn't auto-recognize based on file names, as this is a bit frail.

[radomir9720]

@mosuem no, it doesn't help

[mosuem]

Hm, let me take a look. I am quite busy at the moment, but please ping me if I forget about this.. It should work!

[radomir9720]

[mosuem]

Ah I misunderstood, thanks for the screenshot. I thought this was about the template not being recognized.

The region-specific file is expected to inherit messages from the base locale if a key is missing.

I didn't understand it that way - why do you assume this? Honestly asking, we should follow standards with this package.

[radomir9720]

I understand your perspective. This extension likely serves various frameworks, each with its own best practices. Let me explain why it works well for me.

I employ this extension in my Flutter projects. The most popular tool for localization in Flutter is the Flutter Intl extension by Localizely. This tool generates Dart code from arb files. For example, here's a sample of a localization file it produces:

// ignore: unused_import
import 'package:intl/intl.dart' as intl;
import 'localizations.res.dart';

// ignore_for_file: type=lint

/// The translations for English (`en`).
class AppLocalizationsEn extends AppLocalizations {
  AppLocalizationsEn([String locale = 'en']) : super(locale);

  @override
  String get homeNavigationTabPlansCaption => 'Plans';

  @override
  String get homeNavigationTabProfileCaption => 'Profile';
}

/// The translations for English, as used in the United States (`en_US`).
class AppLocalizationsEnUs extends AppLocalizationsEn {
  AppLocalizationsEnUs() : super('en_US');
}

As you can see, the extension correctly identifies that the region-specific en_US locale inherits from the en locale, ensuring all base strings are carried over. If we need to override specific strings, we simply add them to the en_US locale, trigger code generation, and the overrides take precedence in Dart code.

In our scenario, there's no need to duplicate strings from the en file in en_US, as they are automatically inherited during code generation. We could suppress the missingMessagesFromTemplate diagnostics warning, but this is undesirable as it might lead to issues if we genuinely miss a translation string in the base locale file.

To address this, it would be beneficial to add a setting that disables this warning for region-specific translation files when a base locale file is present, while keeping it active for other scenarios such as missing translation strings in the base locale files or when translation strings are missing in the region-specific file and there is no base file for that locale.

[mosuem]

So you would like to disable this for en_US if en is present, but keep it for fr, which would also have en as the template?

[radomir9720]

Yes, exactly

[mosuem]

We could define a new @@x- key for something like "default to template". This could then also be ingested by code generators.

[radomir9720]

Another possible solution is to implement this feature without introducing a new @@x- key. Instead, we can enable a setting called "inherit region-specific from base" within the extension's preferences. We already have access to the locale of the file we're currently examining. By determining whether this locale is region-specific, we can then search for the corresponding base locale file in the same directory. An optional @@x- key can be used to specify the exact location of the base locale file if it is stored in a different directory.

If we cannot find the base locale file, we should display warnings if there are missing translation strings. However, if the base locale file is successfully located, we do not show warnings for that file. This approach minimizes the time lost due to copy-pasting errors, in my opinion.

[radomir9720]

@mosuem Hi, FYI, I have filled a related issue on the flutter repo about gen_l10n. The gen_l10n works as expected for generating translation strings, but it still adds strings to the untranslated-messages-file that are missing in the region-specific file, but are present in the base locale file. It doesn't understand they are inherited, which causes warning messages.