Can not make RTL language application in WinUI 3

Describe the bug

i want to make my winui 3 app RTL, this means All layouts, including the TitleBar and Custom TitleBar, should be right to left! It is very strange that this was done easily in the previous versions. But it is not possible in the latest version (1.3.2)

Steps to reproduce the bug

I did the following methods none of them change the language/layout of the app

Method	Value	TitleBar	Content
MainWindow Top Level UIElement.FlowDirection	RightToLeft	No Change [LTR]	Yes RTL
Package.appxmanifest	DefaultLanguage = fa-IR or fa	No Change [LTR]	No Change [LTR]
Windows.Globalization.ApplicationLanguages.PrimaryLanguageOverride	fa-IR or fa	No Change [LTR]	No Change [LTR]
Thread.CurrentThread	fa-IR or fa	No Change [LTR]	No Change [LTR]
m_resourceContext.QualifierValues[“Language”]	fa-IR or fa	No Change [LTR]	No Change [LTR]
Custom TitleBar (AppWindow) - Grid.FlowDirection	RightToLeft	No Change [LTR]	No Change [LTR]

Expected behavior

At least one of the above methods should change the language of the program, but nothing happens. I also changed the Windows Language settings, but nothing happens

Screenshots

No response

NuGet package version

Windows App SDK 1.3.2: 1.3.230602002

Packaging type

Packaged (MSIX)

Windows version

Windows 11 version 22H2 (22621, 2022 Update)

IDE

Visual Studio 2022

Additional context

No response

### Tasks

[ghost1372]

tnx, using SetProcessDefaultLayout and WS_EX_LAYOUTRTL EX working fine! however Compared to UWP, many features do not work properly. Why do I need to use PInvoke to change the layout, while UWP provides this possibility by changing the language code?

[DarranRowe]

@soroshsabz The thing to remember here is that, just because the current behaviour is to require setting the layout manually. This doesn’t mean that it is intended or desired behaviour in WinUI 3. Microsoft.UI.Xaml.Window can check the current preferred UI languages and then apply the WS_EX_LAYOUTRTL style to the underlying window if it wants to. This is, IMO, the whole root of the problem. The desktop behaviour is unexpected and it is easy to get caught out if you are used to working with CoreWindow. We’ll see how this is resolved when the issue is closed, however, I would expect that the resolution would only apply to WinUI 3 and not have any surprising effects when applied to a desktop application that uses the Windows App SDK.