Capitalize widget's fields?

[MaxLap]

First off, thanks for the work to provide data the way you do. This is really helpful.

Right now when using french language, the names of currencies aren't capitalized in the Currency picker widget.

While it's true that they wouldn't be capitalized in a sentence, so it's important to have them in this form in the translation data, in the context of a form where it's the start of a line, it would be capitalized. I looked around and didn't find a simple way of doing that. I think I could provide a custom ItemBuilder, but that seems a bit complicated to have to rebuild the whole item's UI just to have the title capitalized.

Ideally, I think this default behavior should be changed to capitalize the first letter of the first word. But that would be backward incompatible, so maybe instead adding a parameter to dictate that would be safer. Documenting the issue with a suggested itemBuilder code could also make this situation easier to correct for users.

What do you think?

[tsinis]

Hey @MaxLap, thanks for using the package. Yes indeed, French currency translations are in lowercase (this is also true for many other languages).
Today I can provide a way to modify those translation maps in TypedLocaleDelegate (perhaps some optional

String Function(MapEntry<Iso, String> translation, TypedLocale locale)?

where MapEntry<Iso, String> translation is the original currency and its name (lowercase in your case). Then on your side, you can check the key type (it's currency) and locale (it's French) and apply capitalization (i.e., something like this method from Intl)? Will it work for you?

[MaxLap]

I understand the idea and it can probably work for my use case. Are you saying doing what you say is possible right now or that you could add such a feature? If already possible, I'm struggling to figure out how to plumb it all.

If I understand correctly, I would add a parameter at the TypedLocaleDelegate that I give to the localizationsDelegates of the MaterialApp to transform the translations? If that is so, this would likely work for my use case, but wouldn't be a general solution since that would replace the proper capitalization that could be used in other contexts that are not the picker.

[tsinis]

Yep @MaxLap, it's possible to do with itemBuilder, but this is not very clean. I'd like to point out that the approach with an optional (since it's a breaking change otherwise) translation formatter (that could be applied only once on cached translations in the TypedLocaleDelegate) should be a quick solution for your request (and could be done in a few hours). In the second half of May, I will downstream this functionality to the l10n_ packages level so it can be used outside of Flutter, obviously.

[tsinis]

@MaxLap, your requested functionality is now available in the main branch. I will try to create a release in the upcoming 12 hours, but you can try it out with the git reference if you want. Let me know if you will need any help. Thanks again!

[tsinis]

It should now be a part of world_countries v3.5.0

[MaxLap]

Thank you very much for the fast development on this. I managed to handle my need with this. Here is some feedback:

• For some reason, I couldn't get it to work with isFra. I ended up using locale.language.name == "French".
• I used intl's toBeginningOfSentenceCase for the casing. It might be helpful to change your example to also use it since that's more likely to be what someone else wants than an all uppercase

Here is the whole TypedLocaleDelegate in that I give to my MaterialApp

TypedLocaleDelegate(
  localeMapResolution: [
    LocaleEntry(Locale('en', ''), TypedLocale(LangEng())),
    LocaleEntry(Locale('fr', ''), TypedLocale(LangFra())),
  ],
  l10nFormatter: (l10n, locale) {
    return locale.language.name == "French" && l10n.key is FiatCurrency
        ? toBeginningOfSentenceCase(l10n.value)
        : l10n.value;
  },
)

I want to highlight that this is not quite a general solution since this loses the information on the proper casing. Should I ever want to display the currency's name in a sentence, then French one would start with capital letters while they shouldn't. I'm not saying I need this (I don't), just noting that there is a potential gap there.

Thanks again!

[tsinis]

Hey @MaxLap

Thanks. Can you provide sample code for that .isFra getter not working (I have tested it on my local device yesterday) or at least put breakpoint on that line and check what's inside of this locale? And just to answer your question — this formatter doesn't affect commonNamesMap method outputs, it only adjusting ones stored in the TypedLocale, so you can always access names map and it will return you original data (there is no hidden global state that will affect it).

P.S. I used toUppercase() just for simplicity, I don't want to make documentation too bloated and introduce additional dependency (intl).

[MaxLap]

Ah, I understand. We are kinda changing a default, but could get the original elsewhere. Thanks

Here is a screenshot of the breakpoint:

Here is a main.dart to reproduce:

import 'package:flutter/material.dart';
import 'package:world_countries/world_countries.dart';
import 'package:flutter_localizations/flutter_localizations.dart';

void main() {
  WidgetsFlutterBinding.ensureInitialized();
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      localizationsDelegates: [
        GlobalMaterialLocalizations.delegate,
        GlobalWidgetsLocalizations.delegate,
        GlobalCupertinoLocalizations.delegate,
        TypedLocaleDelegate(
          localeMapResolution: [
            LocaleEntry(Locale('en', ''), TypedLocale(LangEng())),
            LocaleEntry(Locale('fr', ''), TypedLocale(LangFra())),
          ],
          l10nFormatter: (l10n, locale) {
            if (locale.language.name == "French") {
              print(locale.language.isFra);
            }
            return locale.language.isFra && l10n.key is FiatCurrency
                ? l10n.value.toUpperCase()
                : l10n.value;
          },
        ),
      ],
      supportedLocales: const [
        // English, no country code (takes all english countries)
        Locale('en', ''),
        // French, no country code (takes all french countries)
        Locale('fr', ''),
      ],
      locale: Locale("fr"),
      home: Container(color: Colors.white, child: const CurrencyPicker()),
    );
  }
}

It prints false in console lots of times when run (The result of isFra when the name == "French").

[tsinis]

Thanks a lot, I will check it later today and will get back to you.

[tsinis]

Hey @MaxLap - long story short, it's because of the reference to the instance in getters rather than type check, basically if you change your reference to a compile-time constant, from:

localeMapResolution: [ // No `const` keyword :(

to:

localeMapResolution: const [ // With `const` keyword :)

locale.language.isFra will work as expected. Or even better, you can just remove the whole localeMapResolution in that concrete scenario. Since this resolution looks redundant - the key is the same as the value, and both keys are the only supportedLocales. Anyways, I will adjust the getters in the next releases. Thanks!

[MaxLap]

Alright, removed the localeMapResolution and it did fix the isFra. Thanks

[MaxLap]

Another note on this since I've played a bit more with the result:

• Because the subtitle of each item comes from the namesNative of the FiatCurrency, it is not affected by this translation altering mechanism. So there are still some places with the lower case version.
  

  They are few enough that I don't mind it, but I thought you'd like to know. If this bothers me too much, I'll use the itemBuilder to get a more complete solution.

Thank you

[tsinis]

Yep that's expected for namesNative, and this is the case where I would just use items builder. Because native names could have multiple untyped locales inside, so it would be super tricky to provide a way for devs to adjust this with respect to every locale in type-safe manner.

[tsinis]

@MaxLap, I will keep this discussion open until I'm finished with Dart packages refactoring (need to bump the SDK, update with changes in data sources, inject translations formatters in l10_ packages, etc.). I will ping you here once it's done, but it should be done after mid-May. In meanwhile feel free to let me know any other ideas, feature requests, or any kind of other feedback or questions - I'm glad to help. Thanks again!

[tsinis]

Hi @MaxLap!

The idea is that my package’s theme data for pickers—like CurrencyTileThemeData — works just like Flutter’s ThemeData. You inject UI-related configurations (for example, an item builder that sets a specific way your tiles in pickers will look) globally. This way, you don’t have to configure them repeatedly for each picker. Meanwhile, interactive callbacks such as onSelect remain defined at the widget level (e.g., on CurrencyPicker), ensuring that the theme doesn’t override behavior. So, it's just basically as Flutter SDK idiomatic as possible.

Hope that clarifies it!

[MaxLap]

I understand the idea, my point is that right now I don't think the builder approach works well... or I missed something obvious somewhere.

In my opinion, for a builder approach to work well, it should be relatively simple to reproduce the default behavior to make a tweak to it. Otherwise, it's a sign that the builder function is limited.

Try to re-implement the default CurrencyPicker using such a ThemeData based builder: https://github.com/tsinis/sealed_world/blob/main/packages/world_countries/lib/src/widgets/currency/currency_picker.dart#L61

Here are the problems you will encounter:

• You won't have access to itemNameTranslated, which needs _maybeNameTranslation, which needs nameTranslationCache. All of these are on the widget, which is not available to the builder. So you need to redo that translation logic.
• To define the onPressed, you need to have access to:
  • maybeSelectAndPop, which is again defined on the widget
  • onSelect which is something that was passed to the widget

Basically, if the builder doesn't receive the widget that is being built, it's quite complex to reproduce behaviors, and I think it's actually impossible to get access to the onSelect right now, making it impossible to actually use the builder at ThemeData level.

[tsinis]

Ahh, I think I got it now, and yep, I agree. Will it help to introduce copyWith on the tiles in that case, + provide a default that outputs (of the defaultBuilder) to the builder? So, basically, you will have access to all the properties of the default tiles and use them, or just change a few props and return it as a copy with new data.

[MaxLap]

I've only been doing flutter&dart for a month so I'm not the best reference here.

Giving a built default tile to the builder is an interesting idea, but if instead the whole widget was given, then the custom builder could build that tile if needed, and access to any property would be possible.

Then yeah, I guess a copyWith on the tile could be useful in that case.

[tsinis]

Cool, but as it's a breaking change, I will have to introduce it in the second half of the year. Thanks for the idea 🙏🏻

[tsinis]

Hey @MaxLap, just letting you know that most of the feature requests (that did not require breaking changes) and fixes are now online in world_countries v3.6.0:

1. Formatters in L10N (String-based now, let's wait till the end of the year and see if Locale will make it to Dart).
2. Fixed isX getters, added new ones (like isFiatCurrency, isWorldCountry, etc.).
3. Added TODO items in the Projects for the rest.

Please let me know if there is anything else you would love to see or struggle with. Thanks!

[MaxLap]

Thanks for the headup! Looks like there was a lot of chores commits in there haha.

[tsinis]

I'm closing this discussion as it looks like it's partially solved. We can open a new one in the world_countries v4 release (end of 2025, beginning of 2026) if needed.

[tsinis]

Hey @MaxLap, sorry for necroposting, but v4 is now live, and it has addressed most issues you mentioned:

1. inconsistent L10N capitalization,
2. inconsistent native names capitalization,
3. not very DevEx-friendly API for default tile customization,

You should now be able to remove previous workarounds. Thanks for your patience and feedback, very appreciated 🙏🏻