Hi
Switching to Arabic changes Dates to to Hijri format. I want them in Gregorian. Also numbers appear in Hindu and I want them in a different locale.
Can I switch to Arabic translation while keeping Dates, Numbers and Currency in English or some other locale ?
Thanks
19 Answer(s)
-
0
Hi @ismcagdas
Angular I just added the following mapping in AppConfig:
{ "from": "ar", "to": "en" }Moment I added a helper method that takes care of mapping Moment locale in AppPreBootstrap. In my case ar-kw was fine:
public static mapCultureForMoment(currentCulture: string): string { const cultureMap = { 'ar': 'ar-kw' }; if (cultureMap[currentCulture]) { return cultureMap[currentCulture]; } return currentCulture; }I still have something to update to reflect this on Date format Pipe
-
0
Ok, got it now :).
When selecting a language, it is set on the server side like this:
Thread.CurrentThread.CurrentCulture = CultureInfoHelper.Get(language); Thread.CurrentThread.CurrentUICulture = CultureInfoHelper.Get(language);In your case, easiest option is sending "en" to server instead of "ar" when user changes the language. You can use localeMappings for this.
A better solution would allow user to select UI Culture and Culture seperately on the UI.
-
0
Hi @ismcagdas
I was able to add the needed configurations that meet my needs, however I'm still experiencing a problem that's only backend related. When I watch the values during debugging I see the date resolved exactly as needed, but when it returns it from the service to client, it's returned again as Hijri. (I even tried it through POSTMAN to avoid any client side effects)
So I guess it's sort of OWIN Middleware you injected that changes Culture in the pipeline. I noticed you have a method called ThreadCultureSanitizer that's injected in your UseAbp OWIN extension, not sure if it's the right place.
I need your help please to know how and where I can override this behavior. (Note again please that I only use AspNetZero and I don't maintain the source of Abp)
Thanks
-
0
Hi @Kasem,
I couldn't be sure if the cause of the problem is ThreadCultureSanitizer or not. But if you think it is the problem, you can add below line as the first line of ConfigureOwinServices method.
Thread.CurrentThread.CurrentUICulture = new CultureInfo("en-US");You can also use this line instead of using my previous suggestion
Thread.CurrentThread.CurrentUICulture.DateTimeFormat = new CultureInfo("en-US").DateTimeFormat;Maybe a different property of Thread.CurrentThread.CurrentUICulture is used for datetime serialization.
-
0
Thanks @ismcagdas
Unfortunately, it didn't work for me yet.
I'll provide an example that may help you reproduce it at your side:
Make your language Arabic
Add the culture changing code first lines of any method that returns datetime (like a DTO that inherit from FullAuditedEntityDto) something like: GetSomethingForEdit()
Observe FirstOrDefaultAsync method result to see the datetime values like CreationTime (you should get it Gregorian not Hijri)
Then check the result returned to client side (you'll get it Hijri again)
So there are two problems I'm looking for a solution for:
- Apply the needed Culture configs somewhere that's applied everywhere in the app
- is the most critical issue, that something changes Culture when it's back from server to client
Thanks
-
0
Hi @Kasem,
Last thing comes to my mind is moment. Can you set it's locale to "en" here as well.
<a class="postlink" href="https://github.com/aspnetzero/aspnet-zero-core/blob/dev/angular/src/AppPreBootstrap.ts#L143-L144">https://github.com/aspnetzero/aspnet-ze ... #L143-L144</a>
-
0
Thanks @ismcagdas
I already have those configurations applied sometime ago, and it helped solve the problem on frontend only.
// moment.locale(abp.localization.currentLanguage.name); // (window as any).moment.locale(abp.localization.currentLanguage.name); let momentLocale = LocalizedResourcesHelper.mapCultureForMoment(abp.localization.currentLanguage.name); moment.locale(momentLocale); (window as any).moment.locale(momentLocale);public static mapCultureForMoment(currentCulture: string): string { const cultureMap = { 'ar': 'en' }; if (cultureMap[currentCulture]) { return cultureMap[currentCulture]; } return currentCulture; }The reason I say it's only backend, because for some reason, CreationTime is stored in database the correct way now (Gregorian). But when I try to edit the record, it's converted to Hijri (on backend only) and returned to client as Hijri. The steps I provided will show exactly what I mean.
-
0
Hi @Kasem,
I reproduced your problem. Here is a workaround;
- First create a class like below in your *.Web.Host project:
public class MyRequestCultureProvider : RequestCultureProvider { public override Task<ProviderCultureResult> DetermineProviderCultureResult(HttpContext httpContext) { var result = new ProviderCultureResult(culture: (StringSegment)"en-US", uiCulture: (StringSegment)"ar"); return Task.FromResult(result); } }Then, use it like this to see if server returns dates with correct format:
app.UseAbpRequestLocalization(opts => { opts.RequestCultureProviders.Insert(0, new MyRequestCultureProvider()); });But, this will work before all request culture providers, so when you change the language on the UI, it will not work. So, you need to execute other request culture localizers in your custom class (like this one <a class="postlink" href="https://github.com/aspnetboilerplate/aspnetboilerplate/blob/master/src/Abp.AspNetCore/AspNetCore/Localization/AbpUserRequestCultureProvider.cs">https://github.com/aspnetboilerplate/as ... rovider.cs</a>), then determine correct uiCulture.
