BLoc, TranslateConverter: target provider is ignored
Karnah opened this issue · 8 comments
Related to #254
BLoc or TranslateConverter are always pass null as target.
https://github.com/XAMLMarkupExtensions/WPFLocalizationExtension/blob/077bac2daeed0c982ff63788fd9839ced3c1c63d/src/Extensions/BLoc.cs#L311
https://github.com/XAMLMarkupExtensions/WPFLocalizationExtension/blob/077bac2daeed0c982ff63788fd9839ced3c1c63d/src/ValueConverters/TranslateConverter.cs#L57
So you cannot override provider for window/page/control. So it always will use LocalizeDictionary.DefaultProvider. This can be a problem for application which use different providers.
Be honest: I tried everything and this is nearly impossibe.
The issue is that BindingBase sealed the ProvideValue and I found till today no way to get into that. I even tried IL Injection, https://harmony.pardeike.net/,...
SO ANY Ideas are highly welcome
For the converter this is not possible, because the converter.
We solve the issue in the way that we define here always the "long" key with assemblyname:resourcename:key
Not so nice but 100% save
We solve the issue in the way that we define here always the "long" key with assemblyname:resourcename:key
We use our own FileLocalizationProvider, which was set as DefaultProvider only in xaml. So it was a bit unexpected when Bloc didn't work. For us it will be easy to fix. If someone uses many own providers, it should be write some provider aggregator and set it as default. But I think it will be useful if to document this.
About fix problem with xaml provider. My dream - refuse Bloc and Translate converter. I'll try check some idea about this and create PR with proof-of-concept
Oh, this is a good point, because my way only works Assembly/Resource/Key and not for a different Provider.
I would be really interested why you use your own provider and If it make sense to make our better,...
Great if you make an PR.
I would be really interested why you use your own provider and If it make sense to make our better,...
We store localization data in files near .exe file. This allows update localization texts without recompilation application. FileLocalizationProvider reads this files and for each culture create Dictionary<string, string>. When I need localized string - I check this dictionary.
If it will be usefull I can create PR with FileProvider - it's not complicated
SO ANY Ideas are highly welcome
1. Bad idea
Add to LocExtension possibility to pass MultiBindingConverter and parameters. Always pass in converter first parameter output value.
<TextBlock >
<TextBlock.Text>
<lex:LocText Key="HelloWorld" Converter="{c:FormatStringConverter}">
<Binding A />
<Binding B />
<Binding C />
</lex:LocText>
</TextBlock.Text>
</TextBlock>I think it is the most common case. But it's looks a bit awful.
2. Not so bad Idea but with breaking changes
Remove Provider overriding. I think most of people uses single provider. It can just set Instance.DefaultProvider and will work as usual. For other people can create some ProviderAggergator which set as default too. Using full keys it can get value from one of internal provider.
For example: we have one provider for strings (from file) and one for images (from resx). I can use simple key for string and "images:key" for images.
But I really don't know how diffcult it will be rewrite for other people.
@Karnah
I will think about your ideas.
What do you think about that idea:
Register Providers with a namesspace, so that you can have a long key that even define the exact provider? Because this could be added in a non breaking change with:
provider:assembly:resource:key
Hmmm. I don't like full keys because they are long and there is easy to make mistakes. Is it possible to use just "provider:key" and automaticly resolve conflicts? Or use separate property for provider name? For example: <lex:Loc Provider="Images" Key="imageKey">