Activities of "kasem"

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.

I think I've solved the first issue by adding Culture date configs in ..AppServiceBase constructor Waiting your feedback about other issue

Thanks @ismcagdas

Unfortunately, it didn't work for me yet.

I'll provide an example that may help you reproduce it at your side:

1. Make your language Arabic

2. Add the culture changing code first lines of any method that returns datetime (like a DTO that inherit from FullAuditedEntityDto) something like: GetSomethingForEdit()

3. Observe FirstOrDefaultAsync method result to see the datetime values like CreationTime (you should get it Gregorian not Hijri)

4. 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:

1. Apply the needed Culture configs somewhere that's applied everywhere in the app
2. is the most critical issue, that something changes Culture when it's back from server to client

Thanks

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

Awesome! thanks a lot

Thank you. I'll try it, but I think this will affect the Arabic translation in server side which is something I'm not interested in. I don't want to affect the translation on frontend and backend, but only change Locale related to Dates, Currency, etc.

Sorry I mean Backend :)

After solving the frontend part, I noticed that Hijri date is still resolved from BE, and nothing to do now with frontend. Can you please guide me to the right place to change this on BE without affecting the translation to Arabic on BE.

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

UPDATE: I think I've managed this by changing locale of Angular and MomentJs. For Angular I added mappings between Arabic and the targeted locale through LocaleMapping. And the same I'm going to do with moment locale