Aggregate targets do not work when language is set to Nepali

[binokaryg]

Describe the bug
When the user language is set to Nepali, the aggregate targets always show 0.

To Reproduce

Steps to reproduce the behavior:

1. Add at least one target in the configuration that has aggregate: true
2. Make sure that the target counter goes up as CHW
3. Set language to English
4. Make sure that the aggregate target counter goes up as a supervisor
5. Change language to Nepali
6. See all the aggregate targets go back to 0

Expected behavior
I expected the aggregate targets to show up regardless of the langauge selected

Logs
No error in the console

Screenshots

Language set to Nepali:

Language set to English:

Language set to French:

Environment

• Instance: local
• Browser: Chrome
• Client platform: Windows
• App: webapp
• Version: 4.15 ~ master

Additional context

When the targets are being fetched, the numerals in the keys are changed to Devanagari (script used for Nepali language).

cht-core/webapp/src/ts/services/target-aggregates.service.ts

Lines 86 to 90 in bed4546

	const opts = {
	start_key: `target~${tag}~`,
	end_key: `target~${tag}~\ufff0`,
	include_docs: true,
	};

[jkuester]

Crazy timing! I have just been trying to chase down why PR for refactoring the target aggregate data flow was suddenly breaking the Nepali language tests....

It is definitely because of this. I did some debugging here and confirmed that when you change the language in the CHT, the LanguageService sets the moment locale. This locale gets used by default for all interactions with moment throughout the webapp code base (including in the lines you linked to in the TargetAggregatesService). However, this locale does not get applied to the instance of moment used in the rules-engine shared-lib when it calculates the target doc Id.

So, the target docs always get written with the default (en) locale date, but when queried in the TargetAggregateService we are not currently adjusting the locale of the date we use (when the user has configured something besides en). I think the fix here is pretty simple (just set the locale to en when getting the interval tag in the TargetAggregateService.

I will include this change in my PR and that should resolve this issue. 👍

[jkuester]

Based on my repo archeology, I think this bug has always existed in the target aggregate logic. The LanguageService has been updating the moment locale since 2.7.0. The original version of the TargetAggregatesService (from 3.9.0) uses basically the same logic for calculating the interval tag with moment.