Repository navigation
Conversation
The 1.x path paged 20 keys per request.
…ove the 1.x editing popups - Dev builds load from the Tolgee API; on failure, the CDN or bundled files - The CDN works without an API key; fallbackOnFail falls back to bundled files - Bundled files are optional; availableLanguages and baseLanguage replace what the API tells about languages - Language tags are kept whole (pt-BR), missing texts fall back to the base language, and Tolgee.init completes with the texts loaded - New Tolgee.languages and Tolgee.reload() BREAKING CHANGE: the 1.x translation popups are removed. In-context editing moves to the tolgee_in_context package.
New tolgee_in_context package with the dialog bridge from the prototype: the tolgee-js dialog runs in the host page on the web and in a transparent WebView elsewhere. tolgee-js is loaded from jsdelivr at a pinned version, and a failed load closes the WebView instead of leaving it over the app. The core package ignores the new folder when publishing and analyzing.
…nd Android TolgeeInContext.install() turns it on in dev builds. Windows and Linux get no editor, since the WebView plugin doesn't support them.
…ee_in_context Four languages, a plural key and a two-key header. Adds web and macOS, and regenerates the Android project for current Flutter and Gradle.
With tolgee_in_context inside the tolgee package, pub either packed it into the tolgee archive or, through the root .pubignore, refused to publish it.
…er a save, log warnings by default - A language that fails to load is left out, so the store keeps its texts and tries again later; an API failure after init no longer switches the session to the bundled files - reload() drops the cached languages it doesn't refresh - Warnings and errors print in debug builds; LogLevel is exported - Docs: the builder must not return Expanded and the like, the StateError for apps without languages, rebuilding MaterialApp after a language change
…oot navigator, time out a hanging editor load
- Test runs analyze and tests in each package - Release bumps both versions and the tolgee constraint of tolgee_in_context, and writes the same entry to both changelogs - Publish publishes tolgee first, then tolgee_in_context once pub.dev serves the new tolgee; its first version is published by hand, since automated publishing needs an existing package
dkrizan
force-pushed
the
dkrizan/flutter-sdk-2
branch
from
November 2, 2026 16:06
ed6a6b4 to
86469e5
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Brings the Flutter SDK closer to tolgee-js. Dev builds get in-context editing with the Tolgee web editor, and release builds stop calling the Tolgee API and never contain the API key.
packages/:tolgee(core) and the newtolgee_in_context(the editor). The editor needs a WebView plugin, and Flutter ships every plugin of every dependency in release apps. Keeping it separate means apps without editing don't carry it. Both are released together with the same version.--dart-defineonly outside release builds. Release builds use the CDN, bundled files or both, with an optional fallback to the files. All texts of a language load in one request.doc/migrating-to-2.mdcovers the upgrade.tolgeeis published first, thentolgee_in_contextonce pub.dev serves the newtolgee.Checked in the example app on web, iOS, Android and macOS against a real Tolgee project: editing and saving, the key picker, start language, plurals, release builds, and CDN failure with and without the fallback.
Release notes
Breaking
tolgee_in_contextpackage, which uses the Tolgee web editorapiKeyandapiUrlare ignored there; pass the key with--dart-define=TOLGEE_API_KEYin dev builds insteadpt-BR), so bundled files are named after themTranslationWidgetmust not returnExpanded,Flexible,Positionedor a sliverNew
fallbackOnFailfalls back to bundled files when it failsavailableLanguagesandbaseLanguagedescribe the languages without the APITolgee.languages,Tolgee.reload()andTolgeeProjectLanguage.localeFixed
Tolgee.initcompletes with the texts loaded, so the first frame no longer shows keysChanged
Before and after releasing
tolgee.iopublisher admin publishes the first version oftolgee_in_contexton pub.dev by hand (frompackages/tolgee_in_context, withpubspec_overrides.yamlmoved aside), then turns on automated publishing for it with the tag patternv{{version}}. Until then, the Publish workflow skips it with a warning.webview_fluttercan't make the WebView transparent there, so the editor covers the app window while it's open.