Open jcmontoya opened 2 years ago
@jcmontoya regarding your iOS publishing issue, please have a look at the Preview 14 release notes here. At the at of the document are hints about how to get building with a paired MacOS working again. Also it is suggested to also update your Visual Studio to the 2.1 Service Release. Last but not least there is a known issue where building and publishing of iOS apps do work, but the result is a white/black screen on the device when running the app. This seems to have been fixed already and is in the pipeline for RC1...
Here mine,, super responsive... and customizable...
Built-in MAUI Control is not customizable... ShellContent as of now cannot be customizable like padding, icon margin, icon color...
All for me is drawings, navigation also is rendered drawing... I will made publicly all beautiful controls when polish..
Looks very good. Looking forward to using your controls.
On Sun, Mar 27, 2022 at 10:28 AM coderbasket @.***> wrote:
Here mine,, super responsive... and customizable...
Built-in MAUI Control is not customizable... ShellContent as of now cannot be customizable like padding, icon margin, icon color...
All for me is drawings, navigation also is rendered drawing... I will made publicly all beautiful controls when polish.. [image: Screenshot_20220327-232300] https://user-images.githubusercontent.com/97447955/160288751-45632589-5fdf-4c27-bfd2-24271fed79d4.jpg
— Reply to this email directly, view it on GitHub https://github.com/dotnet/maui/issues/5595#issuecomment-1079953872, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABT24EJCEZX3U3CU3LDVRYDVCB5CZANCNFSM5RXKDACQ . You are receiving this because you were mentioned.Message ID: @.***>
Hey @jcmontoya thanks for the report! Please report one problem per issue so we can keep track of things better. As for the localization: it would be super helpful if you could add a reproduction project that shows this issue.
Did you also try to set other options like:
Thread.CurrentThread.CurrentCulture = culture;
Thread.CurrentThread.CurrentUICulture = culture;
CultureInfo.DefaultThreadCurrentCulture = culture;
CultureInfo.DefaultThreadCurrentUICulture = culture;
Hi @jcmontoya. We have added the "s/needs-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.
Hi, Yes, we tried it (and generally do it this way) and it doesn't change the culture on iOS: CultureInfo.DefaultThreadCurrentUICulture = CultureInfo.DefaultThreadCurrentCulture = CultureInfo.CurrentUICulture = CultureInfo.CurrentCulture = new CultureInfo("bg"));
Hey @jcmontoya thanks for the report! Please report one problem per issue so we can keep track of things better. As for the localization: it would be super helpful if you could add a reproduction project that shows this issue.
Did you also try to set other options like:
Thread.CurrentThread.CurrentCulture = culture; Thread.CurrentThread.CurrentUICulture = culture; CultureInfo.DefaultThreadCurrentCulture = culture; CultureInfo.DefaultThreadCurrentUICulture = culture;
Yes, I tried all the possible combinations.
When I add different resx files for each language then the compiler says: "ALINK : error AL1012: 'arm64' is not a valid setting for option 'platform'" So I can't compile the application
Got the same error "ALINK : error AL1012: 'arm64' is not a valid setting for option 'platform'"
Use Microsoft.Extensions.Localization NuGet package For Sample: Check out this LocalizationDemo project It is working fine for me
@valliappan16 I've just download the repo that you mention and works perfect for Android and Windows but not for iOS I'm still getting the "ALINK : error AL1012: 'arm64' is not a valid setting for option 'platform'"
Any news @Redth @jfversluis ?
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.
As I mention on another issue 6076#issuecomment:
The AL1012 is gone using the latest version of MAUI and by adding this into the csproj file
<GenerateSatelliteAssembliesForCore>true</GenerateSatelliteAssembliesForCore>
Now error AL1012 is gone but on a windows machine not paired to mac when compiles for iOS does not produce the resources for the different languages.
@jfversluis I think this issue and #6076 are the same
After reviewing the artifacts that are produced by my repo https://github.com/Rabosa616/MauiMultilanguageApp/actions/runs/2887616872 , I do see that the iOS one has the spanish resources. That artifact is produced by a Mac Agent.
When I try to compile on my windows developer machine does not produce it. I´m wondering if is a bug in Visual Studio 2022 preview version on windows machine
I´ve tried without pairing a mac and with paring a mac and produce the same results, also I´ve tried on another machine that never had the preview versions and dotnet sdk 6.0.303 and visual studio 2022 17.3.3 with the same outcome
Hi @jfversluis any news?
I've seen #10342 sets the <GenerateSatelliteAssembliesForCore>true</GenerateSatelliteAssembliesForCore>
hardcoded to true, but that only solve partially the issue.
May be related to https://github.com/xamarin/xamarin-macios/issues/17262
Any solution for the localization problem yet? I seem to have the same issue on MacCatalyst
. Pages in the navigationStack do not seem to change localization dynamically. Only new opened pages contain the correct changed localization.
Any solution for the localization problem yet? I seem to have the same issue on
MacCatalyst
. Pages in the navigationStack do not seem to change localization dynamically. Only new opened pages contain the correct changed localization.
On iOS/Android it is fixed.
Similar problem with the Shell bottom navigation bar, it doesn't respond to localization changes in Android (33) but works fine in iOS. So bottom navigation text doesn't update at all in Android for Shell navigation, only when restarting the app with the localization change.
Verified this issue with Visual Studio Enterprise 17.8.0 Preview 2.0. Can repro on windows and android platform.
I am also facing the exact same problem. The Shell bottom navigation bar doesn't respond to localization changes in Android (33) but works fine in iOS. So bottom navigation text doesn't update at all in Android for Shell navigation, only when restarting the app with the localization change. Any update on this one please?
If you have problems applying new culture after you changed the language, set app's MainPage again with a new root page or shell or whatever you are using, everything will be recreated with the new culture that has been applied using
Thread.CurrentThread.CurrentCulture = culture;
Thread.CurrentThread.CurrentUICulture = culture;
Don't forget to dispose properly everything related to the previous main page, except singletons.
We are seeing something similar. We select a language at startup based on the user preference [this seems to work]. The user then later picks a different language, and we set the current culture in the various places mentioned here and then 'push back' to the splash screen, which reloads our main dashboard page. So far, so good. Diagnostic Logging indicates that 'Managed Thread 1' has the correct culture details.
Now, initiate another navigation to the language select page again and this immediately shows that, somehow, 'Managed Thread 1's culture has changed back. The navigated to page acts as if the culture was never changed which makes sense, as the calling view model already sees the language reversion. So logging and visual behavior indicates that we are back to the original culture setting, but we don't have any code that would do that. Backing out of the page without changing anything results in the view maintaining the previously set label values [likely because they weren't refreshed] and bound values reflecting the 'old' culture again [as these are reloaded when navigating 'back' to the screen].
Is MAUI somehow saving/restoring thread state in a way that doesn't take into account culture changes?
EDIT: Attempt to clarify the flow a little bit.
EDIT (2): An interesting note is that the 'DefaultThreadCurrentUICulture' and 'DefaultThreadCurrentCulture' both retain the appropriately updated value, even though the 'CurrentUICulture' and 'CurrentCulture' properties have reverted.
Description
Localization is not working completely. I am using shell and when I change the language at runtime some texts are changed but not all of them. Some pages in the stack don't get translated. If I close the app and run it again the text in all pages is displayed in the correct language (I am saving the user setting to the device). The Shell menu localization works always, so I think this is a bug.
I also noticed that in Android the Shell flyout disappears when you click on the page content (which I expect is the desired behavior), in windows you have to click in the hamburger button for the flyout to hide. When changing the language programmatically, in windows the application loses the title bar in all the pages, in Android it works as expected.
Using FontAwesome for the icons in shell is nice but the alignment in Android is not very good and there is no padding or margin property to adjust their position.
In preview 13, I was able to publish to my IOs physical device in preview14 not anymore.
Steps to Reproduce
I am using simple app with Shell and some pages to test navigation, localization and theming. I am including a video with the issues:
Code to change language at runtime:
https://user-images.githubusercontent.com/6794769/160248838-2f773a3d-d6ae-4349-beab-a887a6c4610f.mp4
.
Version with bug
Preview 14 (current)
Last version that worked well
Unknown/Other
Affected platforms
iOS, Android, Windows
Affected platform versions
Android 12, Windows 11
Did you find any workaround?
No, I have not tried any work arounds
Relevant log output
No response