History

Roll dependendencies

This rolls depdendencies to latest using
flutter update-packages --force-upgrade

This change includes three code changes:

* Removes charcode from the dependencies allowlist since it no longer
  appears in the transitive closure of dependencies of the flutter,
  flutter_test, flutter_driver, flutter_localizations, and
  integration_test packages.

* Uses Resolver.create instead of the deprecated Resolver constructor.
  The default Resolver constructor has been deprecated in favour of the
  static Resolver.create() factory function, which unfortunately happens
  to be async. Propagated the async-ness up the chain.
  This change was partially reverted and the deprecation ignored in this
  patch until package:coverage can be rolled internally at Google.

* Eliminates the use of the deprecated packagesPath parameter to
  HitMap.parseJson. This parameter was deprecated and replaced with
  packagePath in https://github.com/dart-lang/coverage/pull/370 which
  was part of the overall deprecation of the .packages file in Dart
  itself https://github.com/dart-lang/sdk/issues/48272. The overall goal
  being that end-user code shouldn't need to know about implementation
  details such as whether dependency information is stored in a
  .packages file or a package_info.json file, but rather use the
  package_config package to obtain the package metadata and perform
  other functions such as resolving its dependencies to filesystem
  paths. packagesPath was replaced by packagePath, which takes the path
  to the package directory itself. Internally, package:coverage then
  uses package_config to do the rest of the package/script URI
  resolution to filesystem paths.
  This change was partially reverted and the deprecation ignored in this
  patch until package:coverage can be rolled internally at Google.

This is a pre-update prior to updating flutter_template_images in
https://github.com/flutter/flutter/pull/103739

Issue: https://github.com/flutter/flutter/issues/103371
Issue: https://github.com/flutter/flutter/issues/103775
Issue: https://github.com/flutter/flutter/issues/103830

When re-applying the partially-reverted changes to code coverage,
we'll need to patch host_entrypoint.dart internally to await the Future
that we'll be returning rather than a non-async value.

2022-05-14 16:34:10 -07:00

lib

Adds menuBarMenuLabel, and removes unneeded key localizations (#102100 )

2022-05-09 09:25:52 -07:00

test

[devicelab, flutter_test, ...] rename local functions with _s (#102833 )

2022-05-03 10:29:06 -07:00

pubspec.yaml

Roll dependendencies (#103771 )

2022-05-14 16:34:10 -07:00

README.md

[flutter_localizations] fix README links (#91479 )

2021-10-13 17:53:05 -07:00

README.md

Flutter Framework localizations

This package contains the localizations used by the Flutter framework itself.

See the localization README for more detailed information about the localizations themselves.

Adding a new string to localizations

If you (someone contributing to the Flutter framework) want to add a new string to the MaterialLocalizations, WidgetsLocalizations or the CupertinoLocalizations objects (e.g. because you've added a new widget and it has a tooltip), follow these steps (these instructions are for MaterialLocalizations, but apply equally to CupertinoLocalizations and WidgetsLocalizations, with appropriate name substitutions):

Add the new getter to the localizations class MaterialLocalizations, in flutter_localizations/lib/src/material_localizations.dart.
Implement a default value in DefaultMaterialLocalizations in flutter_localizations/lib/src/material_localizations.dart
Add a test to test/material/localizations_test.dart that verifies that this new value is implemented.
Update the flutter_localizations package. To add a new string to the flutter_localizations package, you must first add it to the English translations (lib/src/l10n/material_en.arb), including a description.

Then you need to add new entries for the string to all of the other language locale files by running:
```
dart dev/tools/localization/bin/gen_missing_localizations.dart
```
Which will copy the English strings into the other locales as placeholders until they can be translated.

Finally you need to re-generate lib/src/l10n/localizations.dart by running:
```
dart dev/tools/localization/bin/gen_localizations.dart --overwrite
```
There is a localization README file with further information in the lib/src/l10n/ directory.
If you are a Google employee, you should then also follow the instructions at go/flutter-l10n. If you're not, don't worry about it.

Updating an existing string

If you or someone contributing to the Flutter framework wants to modify an existing string in the MaterialLocalizations objects, follow these steps:

Modify the default value of the relevant getter(s) in DefaultMaterialLocalizations below.
Update the flutter_localizations package. Modify the out-of-date English strings in lib/src/l10n/material_en.arb.

You also need to re-generate lib/src/l10n/localizations.dart by running:
```
dart dev/tools/localization/bin/gen_localizations.dart --overwrite
```
This script may result in your updated getters being created in newer locales and set to the old value of the strings. This is to be expected. Leave them as they were generated, and they will be picked up for translation.

There is a localization README file with further information in the lib/src/l10n/ directory.
If you are a Google employee, you should then also follow the instructions at go/flutter-l10n. If you're not, don't worry about it.