Closed fotiDim closed 2 years ago
Hi, thanks for the kind words.
Direct reference of the keys, not supported. But you could use variables to fulfill that at runtime.
@roipeker I see. The way to do what you suggest would be
app:
title: My App
screen:
learnMore:
selector:appName:
other: Learn here about {{appName:String}}
and then pass it in the Dart code, correct? Is there a more concise way to express it?
Sorry for not replying sooner. Did not get a notification. What package are you using for intl strings in your app?
Sorry for not replying sooner. Did not get a notification. What package are you using for intl strings in your app?
No worries. I am usingflutter_localizations
. I generate files using flutter gen-l10n
.
@fotiDim Thanks for spotting the bug. No clue when this happened, as not many people seems to be using fts it went unnoticed.
Anyway, already published a fix, please try v1.0.2
You can update the tool with fts upgrade
or flutter pub global activate flutter_translation_sheet
and let me know if it's working for you.
Regarding your particular case, you just need to use variables.
app:
title: My App
screen:
learnMore: Learn here about {{appName}}
Beyond the basic example in the WIKI... your widget must read:
@override
Widget build(BuildContext context) {
final l = AppLocalizations.of(context)!;
final appTitle = l.appTitle;
final learnMore = l.screenLearnMore(appTitle);
return Scaffold(
appBar: AppBar(
title: Text(appTitle),
),
body: Center(
child: Text(learnMore),
),
);
}
learnMore: Learn here about {{appName}}
That works. Thanks! The only thing I noticed is that I have to use double quotes when a text starts with the placeholder.
screen:
learnMore: Learn here about {{appName}}
works, but
screen:
learnMore: {{appName}} learn here about
doesn't and had to be instead:
screen:
learnMore: "{{appName}} learn here about"
Yeah, better play safe with quotes.
Was kinda complicated to find a way to avoid corruption of variables (placeholders) in GSheets when the auto translate runs.
I'm not 100% sure that works reliably as it is. In my experience didn't see any issues so far.
Anyway, Im glad that fts is working for you man. If you are ok now, please close the issue.
Sounds good. Thanks again!
Hi @fotiDim , just pushed a new version with several updates.
your original request included:
resolve_linked_keys: true entry_file: strings/sample.yaml dart: ....
If you still use fts, please let me know how it goes.
@roipeker I gave it a spin but it is not working for me. I added in my trconfig.yaml
:
resolve_linked_keys: true
in order to resolve the keys in compile time. Based on my example above I have:
app:
title: My App
screen:
learnMore: Learn more about {{@:app.title}}
but this prints Learn more about @:app.title
. Perhaps I am missing something.
Hi @fotiDim ,
resolve_linked_keys: true
is a root level property (doesn't go inside dart:
).
Is working fine on my end, (resolving the strings in a json file), and also working with new Fts
localization class at runtime when resolve_linked_keys: false
and output_fts_utils:true
.
Are you using the latest version (^1.0.26) ?
Just checked the arb generation, and also resolves the keys for that output.
Hi @fotiDim ,
resolve_linked_keys: true
is a root level property (doesn't go insidedart:
).Is working fine on my end, (resolving the strings in a json file), and also working with new
Fts
localization class at runtime whenresolve_linked_keys: false
andoutput_fts_utils:true
.Are you using the latest version (^1.0.26) ?
Just checked the arb generation, and also resolves the keys for that output.
Whoopsie. Your first remark was spot on. I had the property accidentally indented by 2 spaces. Damn you YAML!
So all good 👍. Perhaps the documentation can be simplified a bit. It seems a bit intimidating on first sight. I really thought I was missing a step and didn't think to recheck my yaml syntax.
And by the way easy_localization
does not use statically typed properties but strings instead which means that any key resolution might blow up during runtime due to a typo. Your package is 100 times better in that regard and is what drove me away from easy_localization and alike packages. Kudos!
Oh amazing, docs needs cleanup for sure, and so is the config. Having a hard time trying to find out the best (easiest) way though. Did you manage to try Fts util code with the new plugin to write locales on OS?
Did you manage to try Fts util code with the new plugin to write locales on OS?
Are you talking about fts extract
or something else?
dart:
output_fts_utils: true
And @IsmailAlamKhan package
https://pub.dev/packages/fts_system_locale
It is somewhere around the News
Fts reflects my lack of creativity for naming stuffs. Anyway, is meant as a simple option to Intl and easy_localizations packages. Similar api to the latter.
Just do Strings.myApp.tr()
or Fts.useMasterTextAsKeys=true "This is my app".tr()
if you use same text as ypur master strings.yaml (useful when using fts extract to quickly localize a ready made app)
The cool thing is that it doesn't require context, at all. Simplest API, and code already generated for you.
This is an official flutter sample i used to test that feature, took me around 12min to localize that app (obviously lacks the fine tuning edition per language)
@roipeker I see. No, I am not using any of that. I am sure other projects will appreciate this flexibility 👍
I have this strings.yaml:
Instead of repeating
My App
twice is it possible to refer to the appTitle key directly?PS: Thank for the great package! I am surprised it does not have more stars.