Hello,
I'm trying to implement a Localization (Multi Language) Support in a Shared (Not PCL) Solution.
I did some researches and found some useful links like:
https://forums.xamarin.com/discussion/17747/how-to-manage-app-localization
And the Documentation of Xamarin: https://developer.xamarin.com/guides/xamarin-forms/advanced/localization/
However the sample for Shared Solution is seen as a Hack.
And is not very good for Maintain.
I wish to know if any of you guys know a better solution for this problem
Thanks
I'm not exactly sure of the details, but I presume the limitation is due AppResources
being generated as part of the compile process, and the way targets are set up do not correct 'compile' the resources when they're in a Shared Project (which never actually gets compiled, just has it's files included in other projects). Hopefully this is fixed in future...
For now, perhaps you could try adding a PCL project to your solution just for the resources, and reference it in all your other projects? You'd need to ensure the correct assembly is referenced in this code snippet (from the docs):
System.Resources.ResourceManager temp = new System.Resources.ResourceManager( "UsingResxLocalization.Resx.AppResources", typeof(AppResources).GetTypeInfo().Assembly);
^ Note: that isn't something I've tested already, just an idea...
Answers
I'm using the Xamarin solution for this, I can't think of an alternative solution because what it's doing is setting the CultureInfo of the current thread running, however I think it does work well and I've not had any trouble doing it that way.
@seanyda ,
Are you using a Shared Solution or PCL?
If you use Shared, manually sync the gets and sets ,as @CraigDunn said, is time consuming?
"For the default resources AppResources.resx file - which normally would have the AppResources.designer.cs file auto-generated - you must manually keep the C# properties synchronized with whatever string elements you add to the resources XML��. This is going to be incredibly tedious and error prone, so using RESX localiztion with Shared Projects is not typically recommended unless you understand these limitations!"
Sorry my bad, I missed the shared bit. I am using PCL, I hope you sort your issue
I'm not exactly sure of the details, but I presume the limitation is due
AppResources
being generated as part of the compile process, and the way targets are set up do not correct 'compile' the resources when they're in a Shared Project (which never actually gets compiled, just has it's files included in other projects). Hopefully this is fixed in future...For now, perhaps you could try adding a PCL project to your solution just for the resources, and reference it in all your other projects? You'd need to ensure the correct assembly is referenced in this code snippet (from the docs):
^ Note: that isn't something I've tested already, just an idea...
Thank You @CraigDunn !
I will Try that.
@DavidBritch I saw you did the last commit in the github of this sample
It was you that made the code? Could you say exactly what was the limitations that you referred ?
@CraigDunn
Just to give a FeedBack about your Idea...
I was able to use as you mentioned.
However there is a problem.
To use the AppResources of the PCL project in my Shared project I have to change it from an internal class to a public one.
And every time that I change the .resx file and the .cs class from it is recreated, the the keyword goes back to internal.
So after every time I change the .resx I I have to change the .cs class to 'public' again.
Any way.
I was able to solve this using the PublicResXFileCodeGenerator in the customCompiler
Reference:
https://stackoverflow.com/questions/4274311/visual-studio-resx-file-default-internal-to-public
Thanks
@RaphaelChiorlinRanieri yes, that info also appears in our docs
https://developer.xamarin.com/guides/xamarin-forms/advanced/localization/#String_Visibility