Amharic (amh) language added successfully but checkbox remains disabled in Registration Client language selection

1

Hi
as you mentioned i am following these document ( Module Configurations | MOSIP Docs 1.2.0 )

I’m adding Amharic (amh) as an optional language for our MOSIP deployment (Registration Client v1.2.0.2), following the module-configuration docs ( Module Configurations | MOSIP Docs 1.2.0 ). Everything appears correctly configured end-to-end, but the ‘amh’ checkbox in the Registration Client’s Select Language dialog stays visible but disabled/non-clickable. English (mandatory) works fine.

Steps completed so far:

  1. Master data — Inserted amh into master.language (native_name = አማርኛ) and added all 6 levels to master.loc_hierarchy_list. Confirmed via sync that ‘amh’ now appears as an option in the dialog (previously it didn’t show at all).

  2. application-default.properties (on our config git branch, identy-v1.2.0.1) — Set:
    mosip.supported-languages=eng,amh
    mosip.mandatory-languages=eng
    mosip.optional-languages=amh
    mosip.min-languages.count=1
    mosip.max-languages.count=2

  3. Config-server — Discovered our config-server pod had no git label/branch set at all (defaulting to master, not our identy-v1.2.0.1 branch, which is why our properties changes weren’t taking effect even though the Helm values file showed gitRepo.version: identy-v1.2.0.1 — the chart wasn’t actually wiring that value into an env var). Fixed by patching the config-server-env-vars ConfigMap to add SPRING_CLOUD_CONFIG_SERVER_GIT_DEFAULT_LABEL=identy-v1.2.0.1, then restarted the deployment.

  4. Verified all the way down the chain — Queried the kernel syncdata-service directly (curl …/actuator/env) and confirmed it correctly resolves:
    mosip.supported-languages = eng,amh
    mosip.optional-languages = amh
    mosip.max-languages.count = 2
    …all sourced from our git branch’s application-default.properties. So config-server → syncdata-service is confirmed fully correct.

  5. Registration Client — Ran Check Updates + Synchronize Data multiple times (including full app restart, not just re-login) after each backend change. Sync logs (registration.log) show ‘config data sync is completed’ with no errors, and GlobalParamDAOImpl shows ‘Save Global Params’ succeeding.

  6. Artifactory / i18n resource files — Discovered resources.zip (served from artifactory, which stores it on ephemeral container storage) was missing messages_amh.properties — only labels_amh.properties had been added previously. Rebuilt the zip with both labels_amh.properties and messages_amh.properties included (16 files total) and re-uploaded to the artifactory pod’s reg-client resources.zip. Verified via unzip -l that both files are now present.

Current state: Despite all of the above, after another Check Updates + Synchronize Data cycle, the amh checkbox in the Select Language dialog is still visible in the list but remains disabled/not clickable. English remains selectable as before.

Questions:

  • Is there another sync job or cache (beyond config data sync / master data sync) that governs whether a language checkbox is enabled vs. just displayed?
  • Is there a separate local DB table/flag (e.g., in the Registration Client’s embedded DB) that needs to be explicitly updated for a language to become selectable, beyond global_param and master.language?
  • Are there additional required artifacts (e.g., UI spec JSON per screen needing amh label entries, or a specific i18n resource naming/location) beyond labels_amh.properties and messages_amh.properties in resources.zip?

Happy to share logs/screenshots if that helps. Any pointers appreciated.

Environment: MOSIP sandbox-v2, Registration Client 1.2.0.2, config-server 12.0.1 (chart), kernel-syncdata-service 1.2.0.1.
please share the specific document if you have .. it would be more helpful

image
image1920×1080 279 KB

2

Hi @HariHaran_R ,

Thank you for reaching out to us.

Could you please share the relevant logs for the issue? This will help us investigate the root cause and assist you in resolving it as quickly as possible.

Regards,
Team MOSIP

3

Hi Varaniya1, thanks for the quick response. Here’s the screenshot of the error from the Registration Client startup log:

We followed the module configuration guide ( Module Configurations | MOSIP Docs 1.2.0 ) to add amh as an optional language — setting mosip.optional-languages, mosip.max-languages.count, etc. in application-default.properties, and adding amh to master.language.

We’ve also already created and uploaded the required resource bundle files — labels_amh.properties and messages_amh.properties (copied from the English versions and translated) — into the resources.zip served via artifactory, alongside the existing bundles for en, hi, fr, ta, kn, ar. Confirmed both files are present in the live zip via unzip -l.

Despite this, the Registration Client still throws the ResourceBundle error above at startup.

While investigating further, we found that amh has zero rows in several master data tables that every other working language (eng, ara, hin, etc.) has fully populated — specifically master.template (289 rows for eng/ara, 0 for amh), master.reason_list, master.gender, master.doc_type, master.dynamic_field, master.id_type, master.title, master.status_list, master.status_type, master.template_file_format, master.individual_type, master.doc_category, and master.biometric_attribute.

Question: Is this ResourceBundle error tied to the resources.zip labels/messages files specifically, or could missing master data (like master.template) also trigger it? We’re currently populating these tables for amh (copied from eng as placeholders) to test. Would appreciate confirmation on whether this is the right direction, or if there’s a specific document covering the full set of master data required per language (beyond what’s in the module-configuration guide) that we should be following instead.

image
image965×671 38.1 KB

4

Hi @HariHaran_R,

Thanks for sharing the error, this confirms the root cause. To answer your question directly: the REG-INT-002 error is tied to the resource bundle files, not to the missing master data.

REG-INT-002 (RESOURCEBUNDLE is not available for configured languages) is thrown when the client validates its configured language list against the resource bundles available locally on the client machine. Your config chain is working correctly, the client received eng,amh as configured languages. But, it cannot find the amh bundles (labels_amh.properties / messages_amh.properties) in its local resources. This is also why the checkbox stays disabled: the client will not enable a language whose bundles it cannot load. Missing master data rows would never trigger this error, those cause different failures later in the flow (empty dropdowns, template errors during consent/acknowledgement).

The reason your fix hasn’t taken effect: resources.zip is picked up when the client is downloaded/installed, not during Check Updates / Synchronize Data. You re-uploaded the corrected zip to artifactory after the client was already installed, so the running client is still on the old bundle set.

To resolve:

  1. Re-download and reinstall the reg-client from the hosted URL (this pulls the updated resources.zip), or verify/copy both labels_amh.properties and messages_amh.properties into the installed client’s resources folder manually and restart.
  2. Cross-check the filenames match the language code exactly (_amh, lowercase) and the file encoding is consistent with the working bundles, for Amharic script, ensure the values are unicode-escaped or saved in the same encoding as your existing ara files.

Once the bundles are available locally, the startup error should clear and the amh checkbox should become selectable, since everything upstream (config-server → syncdata → client sync) is already verified correct on your side.

On the master data:
Populating those tables is still required and you’re on the right track, master.template, gender, doc_type, doc_category, dynamic_field, etc. are all language-coded and needed for the registration flow to work end-to-end in amh (templates drive the consent page, acknowledgement receipt, and notifications; the rest populate the form dropdowns). Copying the eng rows with lang_code = 'amh' as placeholders and translating iteratively is a valid approach. There is no single document covering the full per-language master data set beyond the module-configuration guide, the existing eng/ara rows in your DB are the most reliable reference. So please continue that in parallel; it won’t fix the startup error, but it’s needed before amh is fully usable in the flow.

Please try the client reinstall and let us know the result.

Thanks and Regards,
Gokulraj C,
Team MOSIP.

5

Hi Gokulraj,

Thanks for the detailed explanation. We tried both approaches you suggested — manually copying labels_amh.properties / messages_amh.properties into the installed client’s local resources folder, and a full reinstall (fresh download + install) — but the REG-INIT-002 ResourceBundle error still occurs and the checkbox remains disabled.

A few specific questions:

  1. Naming/syntax: Can you confirm the exact expected filename pattern the client’s ResourceBundle.getBundle() call uses — is it labels_amh (3-letter ISO 639-2, matching our mosip.optional-languages=amh config), or does it expect a 2-letter code like labels_am? We noticed all our other working languages (en, hi, fr, ta, kn, ar) use 2-letter suffixes despite the config itself using 3-letter codes (eng, hin, fra, tam, kan, ara) — we want to confirm whether the bundle filename should follow the config code or the ISO 639-1 short code.
  2. Encoding: Could you confirm the exact encoding/format expected for non-Latin scripts — is it native UTF-8, or does the client require native2ascii-style Unicode escape sequences (\uXXXX) like older Java .properties conventions? We want to rule out an encoding mismatch as the cause.
  3. Reference file: Would it be possible to share a working labels_ar.properties or messages_ar.properties (or point us to where in the registration-client GitHub repo these ship from, if they’re bundled in source rather than only in resources.zip) so we can diff our Amharic file’s structure/encoding directly against a known-working one?
  4. Client-side location: After reinstalling fresh (pulling the updated resources.zip), is there a specific local folder path where the client extracts/expects these bundle files that we should verify directly (separate from the ones bundled in resources.zip on artifactory), in case the reinstall isn’t unpacking them where the client actually looks?

We can share our current labels_amh.properties file content for review if that would help pinpoint the issue.

Thanks again for your help,

Hariharan

type or paste#Demographic Details *******START********
#
search_for_Pre_registration_id=የቅድመ-ምዝገባ መታወቂያ
fetch=ዳታ አምጣ
search=ፈልግ

#(Currently Un-used)
fullName=ሙሉ ስም
ageField=ዕድሜ
gender=ጾታ
male=ወንድ
female=ሴት
maleCode=MLE
femaleCode=FLE
devicetype=የመሳሪያ አይነት
ageDatePicker=የልደት ቀን
addressLine1=አድራሻ መስመር 1
addressLine2=አድራሻ መስመር 2
addressLine3=አድራሻ መስመር 3
region=ክልል
Region=ክልል
city=ከተማ
City=ከተማ
province=ዞን
Province=ዞን
postalCode=የፖስታ ኮድ
PostalCode=የፖስታ ኮድ
zone=ቀበሌ
Zone=ቀበሌ
phone=የሞባይል ቁጥር
email=ኢሜይል አድራሻ
cniOrPinNumber =የማጣቀሻ መታወቂያ ቁጥር
next=ቀጣይ
uinId=የወላጅ/አሳዳጊ RID/UIN
saveState=ሰነዱን ካስቀመጡ/ከሰረዙ በኋላ ሁኔታውን ለማስቀምጥ አስቀምጥ ቁልፍን ጠቅ ያድርጉ
uinIdUinUpdate=የወላጅ/አሳዳጊ UIN
parentRegId=የወላጅ/አሳዳጊ RID
parentUinId=የወላጅ/አሳዳጊ UIN
uinUpdateNavLbl=/ UIN ዝማኔ
parentName=የወላጅ/አሳዳጊ ስም
parentOrGuardianName=የወላጅ/አሳዳጊ ስም
parentOrGuardianUIN=የወላጅ/አሳዳጊ RID/UIN

#Demographic Details Title
titleDemographicPane=ስነ-ህዝብ መረጃ
#Demographic screen language title
language=አማርኛ

# Demographic Details *******END*******


# Document Screen ******START*******
#
#(Currently unused)
POA_DOCUMENT_EMPTY=የአድራሻ ማስረጃ ሰነድ
POI_DOCUMENT_EMPTY=የማንነት ማስረጃ ሰነድ
POR_DOCUMENT_EMPTY=የዝምድና ማስረጃ ሰነድ
DOB_DOCUMENT_EMPTY=የልደት ቀን ሰነድ
save=አስቀምጥ
totalpages=ጠቅላላ ገጾች
scanning=በመቃኘት ላይ...
cancel=ሰርዝ
#Capture button  for bio/documents
crop=ቁረጥ
REF_NUMBER=የማጣቀሻ ቁጥር
#
# Document Screen ******END*******

#Biometric screen ***********START***********
#
exceptionCheckBoxPaneLabel =ልዩ ሁኔታዎችን ምልክት አድርግ
Exception_Photo =የልዩ ሁኔታ ፎቶ
#Exceptions bio attributes
leftIndex=ግራ እጅ - ጠቋሚ ጣት
leftMiddle=ግራ እጅ - መካከለኛ ጣት
leftRing=ግራ እጅ - የቀለበት ጣት
leftLittle=ግራ እጅ - ትንሽ ጣት
leftThumb=ግራ እጅ - አውራ ጣት
rightIndex=ቀኝ እጅ - ጠቋሚ ጣት
rightMiddle=ቀኝ እጅ - መካከለኛ ጣት
rightRing=ቀኝ እጅ - የቀለበት ጣት
rightLittle=ቀኝ እጅ - ትንሽ ጣት
rightThumb=ቀኝ እጅ - አውራ ጣት
leftEye=ግራ ዐይን
rightEye=ቀኝ ዐይን
RightEye=ቀኝ ዐይን
qualityPercent=ጥራት %
thresholdPercent=ደረጃ %
exceptions=ልዩ ሁኔታዎች
fingerprintexception=የጣት አሻራ ልዩ ሁኔታ
iris=ዐይን
leftIris=ግራ ዐይን
rightIris=ቀኝ ዐይን
takePhoto=ፎቶ አንሳ
#Biometric with/without Exception Screen (Not Used)
biometricException=ባዮሜትሪክ ልዩ ሁኔታ
applicantbiometric=አመልካቺ ባዮሜትሪክ
/biometricException=/ ባዮሜትሪክ ልዩ ሁኔታ
#Labels used to show Biometric information in Biometric screen
quality=ጥራት
threshold=ደረጃ
mdsQuality= MDS ጥራት
sdkQuality= SDK ጥራት
lefthandpalm=የግራ እጅ መዳፍ
individualphoto=ፎቶ
exceptionphoto=የልዩ ሁኔታ ፎቶ
righthandpalm=የቀኝ እጅ መዳፍ
thumb=አውራ ጣቶች
lefteye=ግራ ዐይን
percentageValue=80%
righteye=ቀኝ ዐይን
#Scan button label while capturing biometrics
scan=ቃኘ
#Biometric screen used (on hover of the image, labels on scaneed image, etc)
leftHand=ግራ እጅ
rightHand=ቀኝ እጅ
thumbs=አውራ ጣቶች
attempts=ሙከራዎች
applicantname=የአመልካቺ ስም
#Used for Toggle to select exception required (Currently - not in use)
biometricexceptionrequired=ባዮሜትሪክ ልዩ ሁኔታ ያስፈልጋል?
#
#Biometric screen ***********END***********


# Preview Screen ********* START********
#
#Preview screen title
preview=ቅድመ ዕይታ
#Edit option used to edit/modify by navigating from preview screen
edit=አስተካክል
#Preview Template
preRegistrationId=የቅድመ-ምዝገባ መታወቂያ
applicationId=የማመልከቻ መታወቂያ
#exception=Fingerprint exception
demographicInformation=ስነ-ህዝብ መረጃ
years=ዓመታት
foreigner=የውጭ ዜጋ
national=ዜጋ
biometricsHeading=ባዮሜትሪክስ
registrationcenter=የምዝገባ ማዕከል
importantguidelines=አስፈላጊ መመሪያዎች
fingersCount=ጣቶች ({0})
irisCount=ዐይን ({0})
faceCount=ፊት
comma=,
registrationpreview=የምዝገባ ቅድመ ዕይታ
#Preview Screen
modify=ቀይር
consent=ግላዊ መረጃዬን ለማከማቸት እና ለመጠቀም ፈቃዴን እሰጣለሁ።

FINGERPRINT_SLAB_LEFT=ግራ እጅ
FINGERPRINT_SLAB_RIGHT=ቀኝ እጅ
FINGERPRINT_SLAB_THUMBS=አውራ ጣቶች
FACE=ፊት
IRIS=ዐይን
introducer=አስተዋዋቂ
applicant=አመልካቺ
IRIS_DOUBLE=ዐይን
EXCEPTION_PHOTO=የልዩ ሁኔታ ፎቶ
#
# Preview Screen ********* END********

#Authentication / EOD APPROVAL / Re-Registration Screen *************START**********
#
rofingerprintauthentication=በጣት አሻራ ማረጋገጥ
roirisauthentication=RO ዐይን ማረጋገጥ
rofaceauthentication=RO ፊት ማረጋገጥ
supervisorauthentication=የተቆጣጣሪ ማረጋገጫ
operatorauthentication=የኦፕሬተር ማረጋገጫ

#Re-Registration
approved/rejected=\\u24D8 የጸደቁ/የተቀቡ ማመልከቻዎች ሁሉ ከማረጋገጥ በኋላ ተጠናቀቁ ይባላሉ። በቢጫ የተደምቁ የማመልከቻ መታወቂያዎች ተዘጋጊ ቃላት እንዳሉ ያሳያሉ።
packetssyncstatus=የፓኬት ሲንክ ሁኔታ
statusfromserver=ከሰርቨር ያለው ሁኔታ
reasonforrejection=የመቀበያ ምክንያት
informed=ተነገሮታል
cantinformed=ሊነገረው አልቻለም
aplicatoinactioned=ሁሉም ማመልከቻዎች ከተፈጸሙ በኋላ።

photoAuthentication=በፎቶ ማረጋገጥ
irisAuthentication=በዐይን ቅኝት ማረጋገጥ
fpAuthentication=በጣት አሻራ ማረጋገጥ
pwdAuthentication=በይለፍ ቃል ማረጋገጥ
otpAuthentication=በOTP ማረጋገጥ
supervisorPhotoAuth=ተቆጣጣሪ በፎቶ ማረጋገጥ
supervisorIrisAuth=ተቆጣጣሪ በዐይን ቅኝት ማረጋገጥ
supervisorFpAuth=ተቆጣጣሪ በጣት አሻራ ማረጋገጥ
supervisorPwdAuth=ተቆጣጣሪ በይለፍ ቃል ማረጋገጥ
supervisorOtpAuth=ተቆጣጣሪ በOTP ማረጋገጥ

reviewerPhotoAuth=ገምጋሚ በፎቶ ማረጋገጥ
reviewerIrisAuth=ገምጋሚ በዐይን ቅኝት ማረጋገጥ
reviewerFpAuth=ገምጋሚ በጣት አሻራ ማረጋገጥ
reviewerPwdAuth=ገምጋሚ በይለፍ ቃል ማረጋገጥ
reviewerOtpAuth=ገምጋሚ በOTP ማረጋገጥ

#EOD Approval
reasonforonhold=በእቋቋም ምክንያት
pendingapproval=በመጠባበቅ ላይ ያለ ፈቃድ
/pendingapproval=/ በመጠባበቅ ላይ ያለ ፈቃድ
/approveregistration=/ ምዝገባ አጽድቅ
registrationid=የምዝገባ መታወቂያ
registrtionid=የምዝገባ መታወቂያ
authenticate=አረጋግጥ
reject=ውድቅ አድርግ
approve=አጽድቅ

#Re-Registration
reregister=ለድጋሚ ምዝገባ ማሳወቂያ

#
#Authentication / EOD APPROVAL / Re-Registration Screen *************END**********

# Home Page *********START**********
#
regClientVersion = የምዝገባ-ደንበኛ ስሪት
captureTime=የቀረጻ ጊዜ

lastsynctemp=የመጨረሻ ሲንክ - በ
applications=18 ማመልከቻዎች

remap=የማዕከል ዳግም ማሃዘን ሲንክ
logout=ውጣ
eodprocess=የቀን መጨረሻ ሂደት
uploadpacket=ማመልከቻ ስቀል
virusscan=ቫይረስ ቃኘ
syncdata=ዳታ አሳምን
home=መነሻ

internetOnline=ስርዓቱ ኦንላይን ነው
internetOffline=ስርዓቱ ኦፍላይን ነው
synchronizeData=ዳታ አሳምን
downloadPreregistrationData=የቅድመ-ምዝገባ ዳታ አውርድ
updateOperatorBiometrics=የኦፕሬተር ባዮሜትሪክስ አዘምን
endofDayProcesses=የቀን መጨረሻ ሂደቶች
reRegistration=ለድጋሚ ምዝገባ ማሳወቂያ
/reRegistration=/ ለድጋሚ ምዝገባ ማሳወቂያ
viewReport=ሪፖርት ተመልከት
dashBoard=ዳሽቦርድ
newsandUpdates=ዜናዎች እና ዝማኔዎች
viewall=ሁሉንም ተመልከት

checkUpdates=ዝማኔዎችን ፈትሽ
scanqr=QR ቃኘ
#
# Home Page *********END**********


#Packet Upload Screen **********START******
#
operatorId=የኦፕሬተር መታወቂያ
files=የፓኬት መታወቂያ
status=የስቀላ ሁኔታ
upload=ስቀል
/uploadpacket=/ ፓኬት ስቀል
/syncdataprocess=/ ዳታ ማሳምን ሂደት

saveToDevice=ወደ መሳሪያ አስቀምጥ
otp=OTP
#
#Packet Upload Screen **********END****


#Login Screen   ********START******
#
registrationlogin=ግባ
resendotp=OTP ደግሞ ላክ
withusername=የተጠቃሚ ስምዎን ያስገቡ
withpword=የይለፍ ቃልዎን ያስገቡ
withotp=OTP ያስገቡ
username=የተጠቃሚ ስም
password=የይለፍ ቃል
enterotp=OTP ያስገቡ

forgotUsername=የተጠቃሚ ስም ረሱ
forgotPword=የይለፍ ቃል ረሱ
resetPassword=የይለፍ ቃል ዳግም አስጀምር

#
#Login Screen *****END*****


#Registration label to show as a step-step process
/newregistration=/ አዲስ ምዝገባ

#Registration Acknwlegement Title
registration=የምዝገባ ማረጋገጫ

#Acknowledgemenet print request label
print=አትም

#New Registration button label
newregistration=አዲስ ምዝገባ



# Get OTP label Login screen and otp autrh screen
getotp=OTP ውሰድ
nolanguage=ቋንቋ የለም
registrationofficerverification=የምዝገባ ኦፊሰር ማረጋገጫ

submit=አስረክብ

cancelUpperCase=ሰርዝ
submitUpperCase=አስረክብ
selectLanguageText=እባክዎን ለዳታ ግቤት {0} ቋንቋዎችን ይምረጡ። {1} መንግስት ባወጣው መመሪያ መሰረት ነዋሪው መምረጥ ያለበት አስፈላጊ ቋንቋ ነው። የምርጫ ቅደም ተከተል ለስነ-ህዝብ ዳታ የገጽ ዕይታ ያመጣል።
mandatoryLanguage={0} - መንግስት ባወጣው መመሪያ መሰረት ነዋሪው መምረጥ ያለበት አስፈላጊ ቋንቋ ነው።
selectLanguageFooterText=እባክዎን ልብ ይበሉ፣ ቋንቋዎቹ በቅድመ-ምዝገባ ወቅት በገቡት ዳታ ላይ ሊመሰረቱ ይችላሉ።
selectLangError=እባክዎን ቢያንስ አንድ አስፈላጊ ቋንቋ ከዝርዝሩ ይምረጡ።

x=X

/registration=/ አዲስ ምዝገባ


internalsystemerror.pleasecontactadmin.=የውስጥ ስርዓት ስህተት። እባክዎ አስተዳዳሪን ያነጋግሩ።
fingerprint=ጣት አሻራ
previous=ቀዳሚ
rooffice=RO ቢሮ                                          :
roid=RO መታወቂያ                                                :
roname=RO ስም    

onboarduser=የኦፕሬተር ባዮሜትሪክስ አዘምን


aboutus=ስለ እኛ
faq=ተደጋጋሚ ጥያቄዎች
contact=ያግኙን



mosip.io=
uinupdate=UIN ዝማኔ
lostuin=የጠፋ UIN

/lostuin=/ የጠፋ UIN
/uinupdate=/ UIN ዝማኔ

uin=UIN
selecttoupdate=መዘመን ያለባቸውን መረጃዎች ይምረጡ

clear=አጥፋ
close=ዝጋ

running=በሂደት ላይ
lastcompleted=የመጨረሻ ተጠናቅቆ
history=ታሪክ
jobid=የስራ መታወቂያ
jobname=የስራ ስም
lastupdatedtime=የመጨረሻ ዝማኔ ጊዜ
startsyncdata=ዳታ ማሳምን ጀምር
stopsyncdata=ዳታ ማሳምን አቁም


/acknowledgement=/ ማረጋገጫ
goToHome=ወደ መነሻ ሂድ
sendEmail=ኢሜይል / SMS ላክ
downloadPDF=PDF አውርድ


getOnboarded=ምዝገባ ጀምር

homeLink=መነሻ /
onboardOperator= ኦፕሬተር ምዝገባ
/onboardOperator= /ኦፕሬተር ምዝገባ


enterEmail=ኢሜይል መታወቂያ ያስገቡ
enterMobile=የሞባይል ቁጥር ያስገቡ
email/smsAck=ኢሜይል / SMS ማረጋገጫ
send=ላክ
Phone=ስልክ
Email=ኢሜይል
fingerprints=ጣት አሻራዎች

uinno=የUIN ቁጥር ያስገቡ

startOver =ዳግም ጀምር

previewprevious=<  ቀዳሚ
previewnext=ቀጣይ  >
consentHeading=ፈቃድ
back=ተመለስ
continue=ቀጥል
view=ቅድመ ዕይታ


onboardAlertMsg = ተጠቃሚው በተሳካ ሁኔታ ተመዝግቧል


ageOrDOBField = ወይም
userGuide = የተጠቃሚ መመሪያ
registeringIndividual = ግለሰብ መመዝገብ
onboardingYourself = ራስዎን መመዝገብ
synchronizingData = ዳታ ማሳምን
mappingDevices = መሳሪያዎችን ወደ ማሽን መካፈል
uploadingData = ዳታ መስቀል
updatingBiometrics = ባዮሜትሪክስ ማዘምን
parentOrGuardianRID = ወላጅ / አሳዳጊ
parentOrGuardian = ወላጅ / አሳዳጊ
saveToDeviceLable=ማሳሰቢያ: ፓኬቶችን ወደ መሳሪያ ማስቀምጥ ሁሉንም ፓኬቶች ያወጣል
dedupeMessage=ማረጋገጫዎች እየተፈጸሙ ናቸው። እባክዎ ይጠብቁ።
registrationTasks=የምዝገባ ተግባራት
operationalTasks=የስራ ተግባራት

applicantimage=ፎቶ
exceptionimage=የልዩ ሁኔታ ፎቶ
image=ፎቶ
userid=የተጠቃሚ መታወቂያ
role=ሚና
fingerprintimage=የጣት አሻራ ምስል
irisimage=የዐይን ምስል
stationid=የጣቢያ መታወቂያ       :
biometrics=ባዮሜትሪክስ -
capture=ቀርጽ
biometrics_captured=ባዮሜትሪክስ ተቀርጿል
documents=ሰነዶች
date=ቀን
ro_name=የምዝገባ ኦፊሰር
dd=ቀን
mm=ወር
yyyy=ዓ.ም
copyPrevious=ቀዳሚ ቅዳ
exception=ልዩ ሁኔታ
parentUIN=የወላጅ/አሳዳጊ RID/UIN
uinUpdateParentUIN=የወላጅ/አሳዳጊ UIN
fingerprintinstruction=ጣትዎን በስካነር ላይ ያስቀምጡ
irisinstruction=ግራ ዐይንዎን ወደ ስካነር ያቅርቡ
faceinstruction=ፊትዎን ወደ ካሜራ ያቅርቡ
isadult=አመልካቺው አዋቂ ነው?
Foreigner/National = የውጭ ዜጋ/ዜጋ
residenceStatus=የነዋሪነት ሁኔታ
machineID=የማሽን መታወቂያ
registrationCentreID=የምዝገባ ማዕከል መታወቂያ
irisexception=የዐይን ልዩ ሁኔታ
markedasException=እንደ ልዩ ሁኔታ ምልክት ተደርጓል
clicktomarktheparticular=ምልክት ለማድረግ ጠቅ ያድርጉ
finger/Iris= ጣት / ዐይን 
asException=እንደ ልዩ ሁኔታ
documentEvidence=ሰነድ ማስረጃ
selectProForException=ለልዩ ሁኔታ ማስረጃ ይምረጡ
authentication=ማረጋገጫ
biometricDetails=ባዮሜትሪክ መረጃ
uploadDocuments=ሰነዶች ስቀል
demograhpicDetails=ስነ-ህዝብ መረጃ
exceptionCount=ልዩ ሁኔታ
searchRegistration=የምዝገባ መታወቂያ ፈልግ
searchPacketID=የፓኬት መታወቂያ ፈልግ
searchPacketIDOpId=የፓኬት / ኦፕሬተር መታወቂያ ፈልግ
searchApplication=የማመልከቻ መታወቂያ ፈልግ
searchAppIDOpId=የማመልከቻ / ኦፕሬተር መታወቂያ ፈልግ
registrationDate=የምዝገባ ቀን
registrationType=የምዝገባ አይነት
clientStatus=የደንበኛ ሁኔታ
serverStatus=የሰርቨር ሁኔታ
clearFilters=ማጣሪያዎች አጥፋ
statusComments=የሁኔታ አስተያየቶች
slno=ተ.ቁ
eodDate=የምዝገባ ቀን
select=ምረጥ
parentPhoto=የወላጅ ፎቶ
exceptionTracker=ልዩ ሁኔታ
fingerPrintTracker=ጣት አሻራዎች
leftHandTracker=ግራ እጅ
rightHandTracker=ቀኝ እጅ
thumbTracker=አውራ ጣቶች
irisTracker=ዐይን
leftIrisTracker=ግራ ዐይን
rightIrisTracker=ቀኝ ዐይን
photoTracker=ፎቶ
exceptionPhotoTracker=የልዩ ሁኔታ ፎቶ
Index=ጠቋሚ
Middle=መካከለኛ
Ring=የቀለበት
Little=ትንሽ
LeftThumb=ግራ አውራ ጣት
RightThumb=ቀኝ አውራ ጣት
finger=ጣት
scanpreview=የቅኝት ቅድመ ዕይታ
demographicdetailsdemographicdetails=ስነ-ህዝብ መረጃ                                                                              ስነ-ህዝብ መረጃ

availabledevices=ያሉ መሳሪያዎች
mappeddevices=የተካፈሉ መሳሪያዎች
irisscan=የዐይን ቅኝት
guardianBiometric=ወላጆች / አሳዳጊ - ባዮሜትሪክስ

uinUpdateBiometrics=ባዮሜትሪክ
age/dob=ዕድሜ / የልደት ቀን
name=ስም
copyaddress=አድራሻ ቅዳ
applicantbiometrics=አመልካቺ ባዮሜትሪክስ
cnie/pin/residencecardnumber=የማጣቀሻ መታወቂያ ቁጥር
parent/guardiandetails=የወላጅ/አሳዳጊ መረጃ
address=አድራሻ
contactdetails=የዕውቂያ መረጃ
adult=አዋቂ
child=ህፃን

previewHeader=ቅድመ ዕይታ
defaultHeader=የነዋሪ መረጃ
selectLanguage=ቋንቋ ምረጥ

#dashboard template values
totalPacketsLabel=# የተፈጠሩ ፓኬቶች
pendingEODLabel=# በቀን መጨረሻ የሚጠባበቁ
pendingUploadLabel=# ስቀላ የሚጠባበቁ
syncactivities=የሲንክ እንቅስቃሴዎች
version=ስሪት
regclient=የምዝገባ ደንበኛ
idschema=መታወቂያ ስኪማ
installedTime=ፕሮግራሙ የተጫነበት ጊዜ
lastSWUpdate=የመጨረሻ ሶፍትዌር ዝማኔ

withfingerprint=ጣትዎን ለቅኝት በመሳሪያው ላይ ያስቀምጡ
withiris=ዐይንዎን ወደ ስካነር ያቅርቡ
withface=ፊትዎን ወደ ካሜራ ያቅርቡ
stream=ስትሪም

chooselanguage=ቋንቋ ምረጥ

#Settings page
runNow=አሁን አሄድ
lastRun=የመጨረሻ አሂድ: 
nextRun=ቀጣይ አሂድ: 
cronExpression=Cron አገላለጽ:
globalConfigKey=ቁልፍ
serverValue=የሰርቨር ዋጋ
localValue=የአካባቢ ዋጋ
update=አዘምን
submitPreferences=ምርጫዎች አስረክብ
searchKey=ቁልፍ ፈልግ
portRange=የፖርት ክልል:
fromPort=ከ ፖርት
toPort=ወደ ፖርት
scanNow=አሁን ቃኘ
serialNumber=ሲሪያል ቁጥር: 
make=ሰሪ: 
model=ሞዴል: 
deviceId=መታወቂያ: 
deviceName=ስም: 
webcam=ዌብ ካሜራ
wia=WIA
refreshStatus=የመሳሪያ ሁኔታ አድስ
addShortcut=ወደ መነሻ ስክሪን አቋራጭ ጨምር

officerbiometrics=ተቆጣጣሪ / ኦፕሬተር ባዮሜትሪክስ

correctionregistration=የማስተካከያ ሂደት

additionalInfoRequestId=ተጨማሪ መረጃ ጥያቄ መታወቂያ

FingersLabel=ጣቶች
IrisLabel=ዐይን
FaceLabel=ፊት
Users=ተጠቃሚዎች

accept_word=ተቀበል
slash= / 
reject_word=ውድቅ አድርግ
 code here
6

Hi @HariHaran_R,

Good to know, your question #1 is exactly the root cause.
I checked the 1.2.0.2 source to confirm this. The answer is clear: the bundle filenames must use the 2-letter ISO 639-1 code, not the 3-letter config code. Rename your files to labels_am.properties and messages_am.properties.

1. Naming: This is the root cause of the problem. In ApplicationContext.loadResourceBundle() (registration-services, 1.2.0.2), the client converts each configured 3-letter code to its ISO 639-1 alpha-2 equivalent using the com.neovisionaries.i18n.LanguageAlpha3Code library. It builds a Locale from that 2-letter code, and calls ResourceBundle.getBundle("labels", locale). So for amh it resolves Locale("am") and looks for labels_am.properties, a file named labels_amh.properties is never a candidate, which is why both your manual copy and the fresh reinstall still failed. If the bundle for that locale isn’t found, it throws exactly the REG-INIT-002 you’re seeing. This also explains the pattern you noticed with the existing languages, kan → kn confirms it’s the ISO mapping (a substring approach would have produced ka).

2. Encoding: Native UTF-8 is fine - the bundles are loaded via PropertyResourceBundle, which reads UTF-8 by default on the client’s Java 11 runtime. Your working ar bundles in the same zip already prove the UTF-8 path works in your setup, and the Amharic content you shared looks correctly encoded. Just make sure the file is saved as UTF-8 without BOM. You can also use \uXXXX escapes. You do not need to convert.

3. Reference files: The working bundles ship from the registration-client repo itself. You can compare them directly to labels_ar.properties and messages_ar.properties at the 1.2.0.2 tag (path: registration/registration-client/src/main/resources/). Structurally, your file looks right, only the filename is the problem.

4. Client-side location: The bundles are resolved from the client’s classpath, which is the same location where labels_en.properties lives in your installed client. For a quick verification before repackaging: locate where labels_en.properties sits in the installed client (inside the client jar/resources on the classpath) and place the renamed labels_am.properties / messages_am.properties alongside it, then restart. Once confirmed, update the filenames in your resources.zip on artifactory so fresh installs pick them up going forward.

After you rename the files, the REG-INIT-002 error should go away. The amh checkbox should become selectable. The language dialog only enables languages whose bundles were successfully registered at startup, which’s why you are seeing both symptoms.

Please remember that the master data population we discussed earlier is still needed for the end-to-end flow. So do continue that in parallel.

Let us know how it goes after you rename the files.

Thanks and Regards,
Gokulraj C,
Team MOSIP.

7

Hi Gokulraj,

Following your fix, we renamed the bundle files to labels_am.properties / messages_am.properties (confirmed correct Amharic content inside, e.g. ሙሉ ስም, ጾታ) and re-deployed them to our artifactory pod as follows:

How we deployed the files to artifactory:

  1. Our artifactory pod runs as a non-root user (mosip, uid 1001) by default, so resources.zip is write-protected
  2. We temporarily patched the deployment’s securityContext to runAsUser: 0 to get write access:
   kubectl patch deployment artifactory -n artifactory --patch '{"spec":{"template":{"spec":{"securityContext":{"runAsUser":0}}}}}'
  1. Extracted the current resources.zip from the pod, removed the incorrect labels_amh.properties / messages_amh.properties files, confirmed only the correctly-named labels_am.properties / messages_am.properties remained
  2. Re-zipped and re-uploaded via kubectl cp, replacing the old resources.zip in /usr/share/nginx/html/artifactory/libs-release-local/reg-client/
  3. Verified via unzip -l on the pod that the live zip now only contains the correct _am files (no _amh leftovers)

We then did a completely fresh Registration Client install (deleted old install folder, redownloaded, confirmed no cached files) to make sure it pulled the updated resources.zip, per your earlier note that this only happens at install time.

Result: The client did not crash outright this time — it progressed past the error into normal startup (global params fetch, network checks, login service reached). However, the amh checkbox is still disabled, and we see this specific log line:

2026-07-15 13:03:49,042 ERROR [JavaFX-Launcher] i.m.r.c.ApplicationContext : ResourceBundle not found for configured langcode

Notice the langcode value itself is blank — not amh, not am. eng resolves fine (no error logged for it). Since we’ve confirmed the correctly-named am files are present in the live resources.zip and the install is fresh, this looks like it could be the LanguageAlpha3Code conversion returning empty/null specifically when processing amh, rather than a file-location issue.

Could you help clarify: is there a known issue with this specific alpha-3 code (amh) not mapping correctly via the com.neovisionaries.i18n.LanguageAlpha3Code library, or could this blank value point to something else in the config parsing (e.g., how mosip.optional-languages is split/iterated)?

Our current config:

mosip.supported-languages=eng,amh
mosip.mandatory-languages=eng
mosip.optional-languages=amh

Happy to share more log context or our artifactory deployment YAML if helpful.

Thanks,
Hariharan

logs

2026-07-15 13:03:40,361 INFO [JavaFX-Launcher] i.m.r.c.DaoConfig : REGISTRATION - DAO Config - DB - REGISTRATION - REG - Security setup check is complete & success.
2026-07-15 13:03:40,362 INFO [JavaFX-Launcher] i.m.k.c.s.i.TPMClientCryptoServiceImpl : ccSessionID - TPM -  - Getting Asymmetric Key Creation from tpm
2026-07-15 13:03:43,994 INFO [JavaFX-Launcher] i.m.k.k.h.i.KeyStoreImpl : ksSessionId - KeyStoreImpl-Main - KeyStoreImpl - Found Clazz to load for Keystore Impl: io.mosip.kernel.keymanager.hsm.impl.offline.OLKeyStoreImpl
2026-07-15 13:03:43,994 INFO [JavaFX-Launcher] i.m.k.k.h.i.KeyStoreImpl : ksSessionId - KeyStoreImpl-Main - KeyStoreImpl - Successfully loaded Clazz for Keystore Impl: io.mosip.kernel.keymanager.hsm.impl.offline.OLKeyStoreImpl
2026-07-15 13:03:47,328 INFO [JavaFX-Launcher] i.m.k.b.p.f.BioAPIFactory : Starting initialization for vendor mockvendor with params >> {IRIS={version=0.9, threshold=60, args=, classname=io.mosip.mock.sdk.impl.SampleSDK}, FINGER={threshold=60, classname=io.mosip.mock.sdk.impl.SampleSDK, version=0.9, args=}, FACE={threshold=60, classname=io.mosip.mock.sdk.impl.SampleSDK, args=, version=0.9}}
2026-07-15 13:03:47,425 INFO [JavaFX-Launcher] i.m.k.b.p.i.BioProviderImpl_V_0_9 : Successfully registered SDK : sample, BiometricFunction: QUALITY_CHECK
2026-07-15 13:03:47,425 INFO [JavaFX-Launcher] i.m.k.b.p.i.BioProviderImpl_V_0_9 : Successfully registered SDK : sample, BiometricFunction: CONVERT_FORMAT
2026-07-15 13:03:47,425 INFO [JavaFX-Launcher] i.m.k.b.p.i.BioProviderImpl_V_0_9 : Successfully registered SDK : sample, BiometricFunction: EXTRACT
2026-07-15 13:03:47,426 INFO [JavaFX-Launcher] i.m.k.b.p.i.BioProviderImpl_V_0_9 : Successfully registered SDK : sample, BiometricFunction: MATCH
2026-07-15 13:03:47,426 INFO [JavaFX-Launcher] i.m.k.b.p.i.BioProviderImpl_V_0_9 : Successfully registered SDK : sample, BiometricFunction: QUALITY_CHECK
2026-07-15 13:03:47,426 INFO [JavaFX-Launcher] i.m.k.b.p.i.BioProviderImpl_V_0_9 : Successfully registered SDK : sample, BiometricFunction: CONVERT_FORMAT
2026-07-15 13:03:47,426 INFO [JavaFX-Launcher] i.m.k.b.p.i.BioProviderImpl_V_0_9 : Successfully registered SDK : sample, BiometricFunction: EXTRACT
2026-07-15 13:03:47,426 INFO [JavaFX-Launcher] i.m.k.b.p.i.BioProviderImpl_V_0_9 : Successfully registered SDK : sample, BiometricFunction: MATCH
2026-07-15 13:03:47,426 INFO [JavaFX-Launcher] i.m.k.b.p.i.BioProviderImpl_V_0_9 : Successfully registered SDK : sample, BiometricFunction: QUALITY_CHECK
2026-07-15 13:03:47,426 INFO [JavaFX-Launcher] i.m.k.b.p.i.BioProviderImpl_V_0_9 : Successfully registered SDK : sample, BiometricFunction: CONVERT_FORMAT
2026-07-15 13:03:47,426 INFO [JavaFX-Launcher] i.m.k.b.p.i.BioProviderImpl_V_0_9 : Successfully registered SDK : sample, BiometricFunction: EXTRACT
2026-07-15 13:03:47,426 INFO [JavaFX-Launcher] i.m.k.b.p.i.BioProviderImpl_V_0_9 : Successfully registered SDK : sample, BiometricFunction: MATCH
2026-07-15 13:03:47,714 INFO [JavaFX-Launcher] i.m.r.c.RestartController : REGISTRATION - RESTART  - RESTART CONTROLLER - REGISTRATION - REG - Initiate Restart Timer started
2026-07-15 13:03:47,714 INFO [JavaFX-Launcher] i.m.r.c.RestartController : REGISTRATION - RESTART  - RESTART CONTROLLER - REGISTRATION - REG - Creation of sync restart timer started
2026-07-15 13:03:47,714 INFO [JavaFX-Launcher] i.m.r.s.c.i.JobConfigurationServiceImpl : REGISTRATION - SYNC - Job_Configuration_Service - REGISTRATION - REG - Getting Re-start time started
2026-07-15 13:03:47,730 INFO [JavaFX-Launcher] i.m.r.s.c.i.JobConfigurationServiceImpl : REGISTRATION - SYNC - Job_Configuration_Service - REGISTRATION - REG - Getting Re-start time completed
2026-07-15 13:03:47,732 INFO [JavaFX-Launcher] i.m.r.c.RestartController : REGISTRATION - RESTART  - RESTART CONTROLLER - REGISTRATION - REG - Creation of sync restart timer completed
2026-07-15 13:03:47,732 INFO [JavaFX-Launcher] i.m.r.c.RestartController : REGISTRATION - RESTART  - RESTART CONTROLLER - REGISTRATION - REG - Initiate Restart Timer completed
2026-07-15 13:03:48,803 INFO [JavaFX-Launcher] i.m.r.u.SoftwareUpdateHandler : Checking for current version started...
2026-07-15 13:03:48,804 INFO [JavaFX-Launcher] i.m.r.u.SoftwareUpdateHandler : Checking for current version completed : 1.2.0.2
2026-07-15 13:03:48,804 INFO [JavaFX-Launcher] i.m.r.u.SoftwareUpdateHandler : Inside updateDerbyDB currentVersion: {} and {} : {} - 1.2.0.2 - mosip.reg.services.current.version - 0
2026-07-15 13:03:48,920 INFO [JavaFX-Launcher] i.m.r.u.SoftwareUpdateHandler : Backup Path found: 
2026-07-15 13:03:48,920 INFO [JavaFX-Launcher] i.m.r.u.SoftwareUpdateHandler : Backup folder not found, returning the version as the same: 
2026-07-15 13:03:49,042 ERROR [JavaFX-Launcher] i.m.r.c.ApplicationContext : ResourceBundle not found for configured langcode 
2026-07-15 13:03:49,046 INFO [JavaFX-Launcher] i.m.r.s.c.i.GlobalParamServiceImpl : Fetching list of global params
2026-07-15 13:03:49,047 INFO [JavaFX-Launcher] i.m.r.d.i.GlobalParamDAOImpl : REGISTRATION - GLOBALPARAMS - GLOBAL_PARAM_DAO_IMPL - REGISTRATION - REG - Fetching list of global params
2026-07-15 13:03:49,131 INFO [JavaFX-Launcher] i.m.r.d.i.GlobalParamDAOImpl : REGISTRATION - GLOBALPARAMS - GLOBAL_PARAM_DAO_IMPL - REGISTRATION - REG - List of global params fetched successfully
2026-07-15 13:03:49,162 INFO [JavaFX-Launcher] i.m.r.u.r.ServiceDelegateUtil : Registration Network Checker had been called --> https://api-internal.sandbox.apinodes.com/v1/syncdata/actuator/health
2026-07-15 13:03:49,441 INFO [JavaFX-Launcher] i.m.r.s.l.i.LoginServiceImpl : REGISTRATION  - LOGINSERVICE - REGISTRATION - REG - Started Initial sync
2026-07-15 13:03:49,441 INFO [JavaFX-Launcher] i.m.r.s.s.i.PolicySyncServiceImpl : Entering into get public key method.....
2026-07-15 13:03:49,441 INFO [JavaFX-Launcher] i.m.r.u.r.ServiceDelegateUtil : Registration Network Checker had been called --> https://api-internal.sandbox.apinodes.com/v1/syncdata/actuator/health
2026-07-15 13:03:49,476 INFO [JavaFX-Launcher] i.m.r.d.i.GlobalParamDAOImpl : REGISTRATION - GLOBALPARAMS - GLOBAL_PARAM_DAO_IMPL - REGISTRATION - REG - Get Global Param
2026-07-15 13:03:49,507 INFO [JavaFX-Launcher] i.m.r.d.i.RegistrationCenterDAOImpl : checking if Registration Center details exists and is active
2026-07-15 13:03:49,521 INFO [JavaFX-Launcher] i.m.r.s.s.i.PolicySyncServiceImpl : Calling getCertificate rest call with request params {applicationId=KERNEL, referenceId=SIGN}
2026-07-15 13:03:49,529 INFO [JavaFX-Launcher] i.m.r.u.SoftwareUpdateHandler : Checking for current version started...
2026-07-15 13:03:49,529 INFO [JavaFX-Launcher] i.m.r.u.SoftwareUpdateHandler : Checking for current version completed : 1.2.0.2
2026-07-15 13:03:49,533 INFO [JavaFX-Launcher] i.m.r.u.a.RestClientAuthAdvice : Auth advice triggered to check add authZ token to web service request header...
2026-07-15 13:03:49,533 INFO [JavaFX-Launcher] i.m.r.u.r.AuthTokenUtilService : fetchAuthToken invoked for triggerPoint >>>>> triggerPoint
2026-07-15 13:03:49,544 INFO [JavaFX-Launcher] i.m.r.u.a.RestClientAuthAdvice : Adding authZ token to request header
2026-07-15 13:03:49,544 INFO [JavaFX-Launcher] i.m.r.u.a.RestClientAuthAdvice : Adding of authZ token to request header completed
2026-07-15 13:03:49,743 INFO [JavaFX-Launcher] i.m.r.u.a.ResponseSignatureAdvice : Response signature advice triggered...
2026-07-15 13:03:49,747 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId - applicationId - SERVER-RESPONSE - Request received to getCertificate
2026-07-15 13:03:49,747 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId - referenceId - Optional[SIGN-VERIFY] - Request received to getCertificate
2026-07-15 13:03:49,747 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId -  -  - Reference Id is present. Will get Certificate from DB store
2026-07-15 13:03:49,747 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId - applicationId - SERVER-RESPONSE - Getting public key from DB Store
2026-07-15 13:03:49,747 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId - timestamp - 2026-07-15T07:33:49.747869600 - Getting public key from DB Store
2026-07-15 13:03:49,748 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId - referenceId - SIGN-VERIFY - Getting public key from DB Store
2026-07-15 13:03:49,748 INFO [JavaFX-Launcher] i.m.k.k.h.KeymanagerDBHelper : sessionId -  -  - Getting key alias
2026-07-15 13:03:49,761 INFO [JavaFX-Launcher] i.m.k.k.h.KeymanagerDBHelper : sessionId -  -  - Fetching Key Policy for keyPolicyName(Cache): SERVER-RESPONSE
2026-07-15 13:03:49,781 INFO [JavaFX-Launcher] i.m.k.k.h.KeymanagerDBHelper : sessionId -  -  - Fetching Key Policy for keyPolicyName(Cache): BASE
2026-07-15 13:03:49,783 INFO [JavaFX-Launcher] i.m.k.k.h.KeymanagerDBHelper : sessionId - SERVER-RESPONSE - SIGN-VERIFY - PreExpireDays found as key policy:20
2026-07-15 13:03:49,802 INFO [JavaFX-Launcher] i.m.k.k.h.KeymanagerDBHelper : sessionId - keyAlias - [KeyAlias(alias=0f1ce02e-84b1-4d04-9c3d-30a2d2f0be9c, applicationId=SERVER-RESPONSE, referenceId=SIGN-VERIFY, keyGenerationTime=2026-04-24T02:55:03, keyExpiryTime=2029-04-23T02:55:03, status=null, certThumbprint=BB127429D1F8152BA6A653FFAF71B32BD613F5151295D3AC4630686EA8E23817, uniqueIdentifier=4EF41783A16A0FA23560E32A551FC53F6CE93242)] - keyAlias
2026-07-15 13:03:49,803 INFO [JavaFX-Launcher] i.m.k.k.h.KeymanagerDBHelper : sessionId - currentKeyAlias - [KeyAlias(alias=0f1ce02e-84b1-4d04-9c3d-30a2d2f0be9c, applicationId=SERVER-RESPONSE, referenceId=SIGN-VERIFY, keyGenerationTime=2026-04-24T02:55:03, keyExpiryTime=2029-04-23T02:55:03, status=null, certThumbprint=BB127429D1F8152BA6A653FFAF71B32BD613F5151295D3AC4630686EA8E23817, uniqueIdentifier=4EF41783A16A0FA23560E32A551FC53F6CE93242)] - currentKeyAlias
2026-07-15 13:03:49,803 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId - currentKeyAlias - 0f1ce02e-84b1-4d04-9c3d-30a2d2f0be9c - CurrentKeyAlias size is one. Will fetch keypair using this alias
2026-07-15 13:03:49,815 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId - keyFromDBStore - 0f1ce02e-84b1-4d04-9c3d-30a2d2f0be9c - Key in DBStore exists for this alias. Fetching Certificate.
2026-07-15 13:03:49,919 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId - applicationId - SERVER-RESPONSE - Request received to getCertificate
2026-07-15 13:03:49,919 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId - referenceId - Optional[SIGN-VERIFY] - Request received to getCertificate
2026-07-15 13:03:49,920 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId -  -  - Reference Id is present. Will get Certificate from DB store
2026-07-15 13:03:49,920 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId - applicationId - SERVER-RESPONSE - Getting public key from DB Store
2026-07-15 13:03:49,920 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId - timestamp - 2026-07-15T07:33:49.920666600 - Getting public key from DB Store
2026-07-15 13:03:49,920 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId - referenceId - SIGN-VERIFY - Getting public key from DB Store
2026-07-15 13:03:49,920 INFO [JavaFX-Launcher] i.m.k.k.h.KeymanagerDBHelper : sessionId -  -  - Getting key alias
2026-07-15 13:03:49,922 INFO [JavaFX-Launcher] i.m.k.k.h.KeymanagerDBHelper : sessionId - SERVER-RESPONSE - SIGN-VERIFY - PreExpireDays found as key policy:20
2026-07-15 13:03:49,922 INFO [JavaFX-Launcher] i.m.k.k.h.KeymanagerDBHelper : sessionId - keyAlias - [KeyAlias(alias=0f1ce02e-84b1-4d04-9c3d-30a2d2f0be9c, applicationId=SERVER-RESPONSE, referenceId=SIGN-VERIFY, keyGenerationTime=2026-04-24T02:55:03, keyExpiryTime=2029-04-23T02:55:03, status=null, certThumbprint=BB127429D1F8152BA6A653FFAF71B32BD613F5151295D3AC4630686EA8E23817, uniqueIdentifier=4EF41783A16A0FA23560E32A551FC53F6CE93242)] - keyAlias
2026-07-15 13:03:49,922 INFO [JavaFX-Launcher] i.m.k.k.h.KeymanagerDBHelper : sessionId - currentKeyAlias - [KeyAlias(alias=0f1ce02e-84b1-4d04-9c3d-30a2d2f0be9c, applicationId=SERVER-RESPONSE, referenceId=SIGN-VERIFY, keyGenerationTime=2026-04-24T02:55:03, keyExpiryTime=2029-04-23T02:55:03, status=null, certThumbprint=BB127429D1F8152BA6A653FFAF71B32BD613F5151295D3AC4630686EA8E23817, uniqueIdentifier=4EF41783A16A0FA23560E32A551FC53F6CE93242)] - currentKeyAlias
2026-07-15 13:03:49,922 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId - currentKeyAlias - 0f1ce02e-84b1-4d04-9c3d-30a2d2f0be9c - CurrentKeyAlias size is one. Will fetch keypair using this alias
2026-07-15 13:03:49,924 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId - keyFromDBStore - 0f1ce02e-84b1-4d04-9c3d-30a2d2f0be9c - Key in DBStore exists for this alias. Fetching Certificate.
2026-07-15 13:03:49,932 INFO [JavaFX-Launcher] i.m.k.s.s.i.SignatureServiceImpl : SignatureSessionId - JWTSignature -  - Certificate not found in JWT Header.
2026-07-15 13:03:49,995 INFO [JavaFX-Launcher] i.m.r.u.a.ResponseSignatureAdvice : Response signature is valid... https://api-internal.sandbox.apinodes.com/v1/syncdata/getCertificate?applicationId=KERNEL&version=1.2.0.2&referenceId=SIGN
2026-07-15 13:03:49,995 INFO [JavaFX-Launcher] i.m.r.u.a.RestClientAuthAdvice : completed with request Auth advice
2026-07-15 13:03:49,997 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId - applicationId - SERVER-RESPONSE - Request received to getCertificate
2026-07-15 13:03:49,997 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId - referenceId - Optional[SIGN-VERIFY] - Request received to getCertificate
2026-07-15 13:03:49,997 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId -  -  - Reference Id is present. Will get Certificate from DB store
2026-07-15 13:03:49,997 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId - applicationId - SERVER-RESPONSE - Getting public key from DB Store
2026-07-15 13:03:49,999 INFO [JavaFX-Launcher] i.m.k.k.s.i.KeymanagerServiceImpl : sessionId - timestamp - 2026-07-15T07:33:49.997912200 - Getting public key from DB Store
2026-07-15 13:03:49,999 INFO [JavaFX-Launcher] i.m.k.k.s.i.Keymanager
8

Hi @HariHaran_R,

Good progress and your deployment steps helped pinpoint the remaining gap. Answering your questions first, then the actual issue:

  1. The blank langcode is a logging artifact, not a conversion failure. The exact statement in ApplicationContext is LOGGER.error("ResourceBundle not found for configured langcode ", langCode), the message string has no placeholder for the argument, so the langcode is silently dropped from the log output. It always prints blank, for any language. The failing langcode here is amh.
  2. There is no issue with the amh mapping. In the nv-i18n library source, LanguageAlpha3Code.amh.getAlpha2() is hardcoded to return LanguageCode.am, it cannot return empty/null. Your config parsing is also fine (eng from the same list resolves correctly). So both theories can be ruled out.
  3. The actual gap: resources.zip is consumed at client build time, not install time. Looking at registration/configure.sh in the registration-client repo, the flow is:
  • The regclient build job (the job/deployment in your cluster that runs configure.sh) downloads resources.zip from artifactory and merges its contents into registration-client-1.2.0.2.jar
  • That jar is then code-signed and its hash registered in the client’s update MANIFEST
  • The final reg-client.zip served for download is assembled from this

So updating resources.zip on the artifactory pod is the correct source location, but nothing consumes it until the regclient pod is re-run or restarted. Your fresh install simply re-downloaded the same reg-client.zip that was built from the old resources. Please re-run the regclient job in your deployment (delete and re-trigger the regclient pod so configure.sh executes again), wait for it to publish the regenerated client, then do the fresh download + install.

Also note: Manually dropping the properties files into the installed client can never work in this design, the run.bat classpath uses lib/* (a jar wildcard, which does not load loose .properties files from a folder), so the bundles must be inside the signed jar.

After re-running the regclient pod and reinstalling, the jar should list labels_am.properties, and correspondingly messages_am.properties.

Once those files are inside the jar, the bundles will register successfully at startup, and the checkbox will enable. For reference, the dialog resolves each language’s display name from its labels bundle and disables the checkbox when the name falls back to the code, which is exactly your current state.

Let us know the result after re-running the regclient pod.

Thanks and Regards,
Gokulraj C,
Team MOSIP.

9

image
image1920×1080 231 KB

Hi Gokulraj,

Update: your diagnosis was exactly right. We found and re-ran the regclient build job in our cluster, which rebuilt registration-client-1.2.0.2.jar with the corrected labels_am.properties / messages_am.properties baked in (confirmed via jar -tf ... | findstr "labels" — both files are present alongside ar, en, hi, fr, ta, kn). After a fresh install of the resulting client, the amh checkbox is now clickable and selectable. Thank you for the detailed root-cause explanation — the client build vs. install-time distinction was exactly what we were missing.

Two follow-up items:

1. Font rendering issue (Ge’ez script)
With Amharic selected, labels and demographic fields that should show Amharic text are rendering as □□□□ (tofu boxes) instead of actual Ge’ez characters — e.g. “Demographic Information” shows fine in English but the Amharic translation next to it is boxes. We confirmed no Ethiopic-capable font (e.g. Noto Sans Ethiopic) was installed on the Windows client machine, and are testing whether installing one resolves this.

Question: does the Registration Client’s JavaFX UI reference a specific hardcoded font family in its CSS (which might not fall back to an OS font for unsupported glyphs), or should installing a system-wide Ethiopic font (like Noto Sans Ethiopic) be sufficient on its own? Want to confirm before assuming this is purely an OS/font-installation gap versus something that needs a client-side CSS/font-stack change.

2. Making artifactory’s resources.zip storage permanent
During this troubleshooting, we found that our artifactory pod stores resources.zip on ephemeral container storage — any pod restart/recreation reverts it to the original bundled content, which cost us significant time earlier in this process (files we’d uploaded disappeared after an unrelated pod restart).

Is there a recommended approach for making this persistent in a typical sandbox/Helm deployment — e.g., mounting a PersistentVolumeClaim for the artifactory data directory, or is rebuilding a custom artifactory image with the updated resources.zip baked in the preferred pattern? Want to avoid this being lost again on the next routine pod restart.

Thanks again for the thorough help getting Amharic working end-to-end.

Regards,
Hariharan

image
image812×556 12.3 KB

10

Hi @HariHaran_R,

Great to hear the checkbox is now working, thanks for confirming and for sharing the jar verification output.

1. Font rendering (Ge’ez script) — It’s actually both things you suspected, so good instinct splitting the question:

  • The client’s application.css hardcodes -fx-font-family: Roboto across most of the UI, and Roboto has no Ethiopic glyphs. Also note that JavaFX CSS accepts only a single family name in -fx-font-family, there is no comma-separated fallback stack like web CSS and JavaFX’s automatic glyph fallback is unreliable for less common scripts on Windows. So, installing a system font alone may not fix the nodes explicitly styled with Roboto.
  • Quick check first: Windows 10/11 already ship Ebrima, which covers both Latin and Ethiopic. Please verify your Amharic strings render correctly in Notepad with Ebrima, if the OS renders them fine but the client still shows boxes, that confirms the hardcoded CSS font is the blocker (no need to install Noto Sans Ethiopic in that case).
  • The fix uses the same mechanism you just learned: application.css lives at the root of registration-client-1.2.0.2.jar, the same location where resources.zip contents are merged. So a modified application.css placed in your resources.zip will replace the built-in one when the regclient job rebuilds the jar. Take the css from the repo (registration/registration-client/src/main/resources/application.css at the 1.2.0.2 tag), replace Roboto with Ebrima (or your installed Ethiopic-capable font, pick one family that covers both Latin and Ethiopic since only one family can be set), add it to resources.zip, re-run the regclient job, and reinstall.

2. Persisting artifactory content — You’ve hit a real characteristic of the sandbox artifactory: it’s a simple static-file server whose content is baked into the image, so pod-level file edits are ephemeral by design. The recommended pattern is to treat your customized resources.zip as a versioned build artifact and bake it into a custom artifactory image, rather than mounting a PVC:

  • The image sources are in the mosip/artifactory-ref-impl repository, you can either fork it and add your files or simply build a thin custom image: FROM the artifactory image version you’re running, COPY your updated resources.zip over /usr/share/nginx/html/artifactory/libs-release-local/reg-client/resources.zip, push it to your registry, and point your Helm values at the custom image.
  • This survives every pod restart, is upgrade-friendly, keeps your customization in version control, and also removes the need for the runAsUser: 0 patch, which I’d recommend reverting now in any case.
  • A PVC over the html directory works mechanically, but you’d need init logic to populate it, and it silently drifts from the image content on every upgrade, so the custom image is the cleaner long-term pattern, and it’s what country implementations typically do for customized client resources.

Since the original checkbox issue is resolved, it may also help future readers if you mark the relevant post as the solution, and feel free to open a separate topic for the font rendering if it needs deeper follow-up after your test.

Thanks and Regards,
Gokulraj C,
Team MOSIP.

11

Hi Gokulraj,

Quick update — we translated master.gender for amh (FLE→ሴት, MLE→ወንድ, OTH→ሌሎች) and did a fresh Synchronize Data on the Registration Client.

For text/label fields (Full Name, line1, line2, etc.), selecting both English and Amharic correctly shows a second input field for Amharic (currently rendering as □□□□ boxes, which we understand is the separate CSS/font issue you already helped us with).

However, for any database-driven master data field — Gender (Female/Male/Others), Residence Status (Foreigner/Non-Foreigner), and we expect this will extend to document categories, ID types, etc. once we test those too — there’s no Amharic attempt at all. Just plain English text, no second element, no boxes, nothing indicating it tried to load Amharic values for these specific fields, even after translating the DB rows and syncing.

This is a different symptom than the CSS/font issue — for text labels, the app clearly tries to render Amharic (and fails visually due to the font). But for master-data-driven buttons/dropdowns, it seems like the Amharic translation isn’t being picked up or requested at all.

Is there a different sync mechanism, caching layer, or additional client-side configuration needed for these master-data-driven UI elements (gender, individual_type, doc_type, etc.) to actually pick up a newly translated language row — separate from what handles the free-text label fields?

Thanks,
Hariharan

image
image697×400 23.2 KB

image
image1456×810 16.3 KB

12

Hi @HariHaran_R,

Your observation is exactly right, and there’s a clear explanation: in 1.2.0.x, the Registration Client does not read Gender or Residence Status from master.gender / master.individual_type at all — these are dynamic fields, served from master.dynamic_field.

In the client source, MasterSyncServiceImpl.getFieldValues() resolves every non-hierarchical dropdown/button field by querying the local dynamic_field table (synced from the server’s master.dynamic_field) for the given field name and language code. Since dynamic_field has no amh rows, it was one of the zero-count tables in your earlier audit, the query for amh returns empty, and the UI simply has nothing to render for that language.
That’s why you see no Amharic attempt at all, unlike the label fields: labels come from the UI spec and resource bundles (client-side artifacts), while these values are queried per-language from the local DB at render time. Two different data sources, hence the two different symptoms. Your master.gender translation went into a table the client doesn’t consult for this screen.

To fix:

  1. For each dynamic field in your ID schema (gender, residenceStatus, and any others), copy the existing eng row in master.dynamic_field to a new row with lang_code = 'amh': new UUID for id, translate only the "value" entries inside value_json, and keep the "code" values identical across languages (FLE/MLE/OTH etc. The code is what gets stored in the packet, so it must match). Set is_active = true.
  2. Important delta-sync detail: when inserting these rows manually via SQL, set cr_dtimes (and upd_dtimes if you set it) to the current UTC timestamp. The client’s master data sync is delta-based on the last sync time, rows inserted with old/backdated timestamps can be silently skipped by the next sync. This is a common trap when seeding master data by hand.
  3. Run Synchronize Data on the client and re-open the registration form.

For the other master-data-driven elements you’re planning to test:

  • Location dropdowns (region/province/city/zone/postal code) are the hierarchical case, they read from master.location per language, so every location entity needs an amh row for those dropdowns to populate in Amharic.
  • Document categories/types come from master.doc_category / master.doc_type (via applicant_valid_document), so those need amh rows as well, per your original plan.
  • The same timestamp caution from point 2 applies to all of these inserts.

So your original table-by-table population plan was correct, the only adjustment is that for gender/residence status specifically, dynamic_field is the table that matters, not master.gender.

Thanks and Regards,
Gokulraj C,
Team MOSIP.

13

Hi Gokulraj,

Quick update — wanted to separate out what’s confirmed working versus what’s still broken, since these seem to be independent issues.

:white_check_mark: Confirmed working: database/translation pipeline

All 13 master data tables (plus reason_category and template_type, which were FK dependencies we found along the way) are populated with amh rows. Specifically translated gender, doc_category, status_list, and master.dynamic_field entries for gender/residenceStatus:

{"code":"MLE","value":"ወንድ"}
{"code":"FLE","value":"ሴት"}
{"code":"OTH","value":"ሌሎች"}

Confirmed this reaches the client correctly — the Home screen (Operational Tasks, News and Updates) renders real Amharic text perfectly after sync. So the data layer is solid.

:cross_mark: Still broken — Issue 1: Font/CSS boxes

Followed your instructions: replaced Roboto with Ebrima in application.css, found and also updated application-pink.css (both present in the built jar), added to resources.zip, re-ran the regclient job, reinstalled fresh. Confirmed via jar -tf and findstr "font-family" that both CSS files now show -fx-font-family: "Ebrima" throughout. Confirmed ebrima.ttf/ebrimabd.ttf exist in C:\Windows\Fonts, and did a full Windows restart before retesting.

Despite this, Demographic Details still shows □□□□ boxes for Amharic text (Full Name, address lines), while the Home screen renders Amharic correctly. Both screens should presumably use the same CSS — why the difference?

Also, on this same screen, Gender/Residence Status buttons show no Amharic at all (not even boxes) — despite the dynamic_field translations above being confirmed correct in the database and synced. Text fields (Full Name, line1, line2) do show boxes as expected, so it’s specifically the button/dropdown fields that show nothing.

:cross_mark: Still broken — Issue 2: “Center is inactive” error

Separately, selecting only Amharic (not English) for New Registration threw: "You are not Authorized to perform this operation as center is inactive. Please contact Admin." This seems unrelated to language — is this a known issue, or should I look into center/operator configuration separately (possibly not a registration-client question at all)?

Questions:

  1. Why do some screens render Amharic correctly (Home) while others (Demographic Details) still show boxes, despite both CSS files now using Ebrima?
  2. Why would Gender/Residence Status show nothing at all, despite the underlying dynamic_field data being confirmed correct?
  3. Is the “center is inactive” error related to Amharic selection, or a separate admin-side issue?

Happy to share more logs/screenshots as needed.

Thanks,
Hariharan

image
image1920×1080 225 KB

image
image1920×1080 260 KB

14

Hi @HariHaran_R,

Great structured update and good news: all three have clear answers from the client source, and none of them indicate anything wrong in your data pipeline.

1. Home renders Amharic but Demographic Details shows boxes — style class coverage.
Your Roboto → Ebrima replacement only affects nodes whose style classes declare a font-family. The Home screen elements use classes that do (e.g. .operationalTitle, .operationalDetails), so they picked up Ebrima and render correctly — which is also proof your font and CSS pipeline work. The demographic screen’s dynamically built controls, however, use style classes like demoGraphicTextField that have no -fx-font-family rule at all in application.css. So, your replacement never touched them. They inherit JavaFX’s default font (Segoe UI on Windows), which has no Ethiopic glyphs, and JavaFX does not reliably fall back for such scripts → boxes.

The robust fix: add a root-level rule at the top of application.css:

.root {
    -fx-font-family: "Ebrima";
}

JavaFX font properties are inherited, so every node without an explicit font-family, including all the demographic controls, will inherit Ebrima. Keep your existing per-class replacements as they are, add this via the same resources.zip → regclient job → reinstall flow.

2. Gender/Residence Status buttons — working as designed, your data is fine.
In ButtonFxControl, the visible button text is rendered only in the first selected language, the code fetches field values for selectedLanguages.get(0) and builds the buttons from that. Your Amharic values are not ignored though: when the operator clicks a button, the client fetches the values for all selected languages and stores them into the packet demographics, and also joins them into the button’s tooltip. You can verify both right now: hover over a selected Gender button and the tooltip should show the English and Amharic values joined with a slash and if you select Amharic as the first language, the button faces themselves will render the Amharic values. So unlike text fields (one input per language), button/dropdown controls display the primary language only, by design, there’s nothing to fix in your dynamic_field data.

3. “Center is inactive” — it IS language-related, and it’s the same pattern again.
In RegistrationCenterDAOImpl.isMachineCenterActive(), the client checks the center by querying the local registration_center table for a row matching the center ID and the application language, which is your first selected language. master.registration_center is a per-language table, and it wasn’t in your populated list, so with only Amharic selected, the lookup for lang_code = 'amh' finds no row, the check returns false, and the client reports the center as inactive. Nothing is wrong with your center or operator configuration with English selected first, it works because the eng row exists.

Fix: copy the eng row(s) for your center in master.registration_center to lang_code = 'amh' (same center id, translated name/address fields), with the same current-timestamp caution as before, then run Synchronize Data. If you later hit similar “not authorized/inactive” errors in Amharic-only mode, check whether the entity involved has a language-coded master table; it’s the same root pattern.

With the .root font rule and the registration_center rows, you should have a fully working Amharic registration flow end-to-end.

Thanks and Regards,
Gokulraj C,
Team MOSIP.

15

I have changed the tables in the database wherein ahm need to be updated/inserted, also in the UI-Spec table. The ahm language is coming fine on all the pages of registration client. , but in the preview page, the ahmeric font is not rendering . Can you advise me on that? Beside this, when I enroll using only english, the packets get stuck at "Upload Packet " Stage. Does my changes related to amh impacting this anyway?

image
image1345×767 114 KB

image
image1920×1080 204 KB

16

Hi @HariHaran_R,

Great to hear Amharic is now rendering across all the form pages. The two remaining items are unrelated to each other, and the second one is not caused by your amh changes details below.

1. Preview page font — different rendering engine, needs the font set inside the template, not application.css.
The preview and acknowledgement pages are not JavaFX form screens — they are HTML rendered inside a JavaFX WebView (a browser engine): the client generates the HTML from the template and calls webView.getEngine().loadContent(...). Because it’s a browser context, your application.css / .root Ebrima rule does not apply to it at all — that’s why every other page now works, but the preview still shows boxes.

The font for this page has to be set inside the template HTML itself, which comes from the master.template table (the Preview/Acknowledgement template for your ID schema). Edit that template’s styling to specify an Ethiopic-capable font, e.g. wrap or prepend a style rule:

<style> * { font-family: "Ebrima", "Nyala", sans-serif; } </style>

(Unlike JavaFX CSS, the WebView is a real browser engine, so a comma-separated font-family fallback list does work here). Update the template row for both the eng and amh language entries, sync, and the preview will render Amharic. If your template pulls a stylesheet by URL instead of inline styles, add the rule there.

2. “Upload Packet” stuck — this is a client↔server connectivity/status issue, independent of language.
This is almost certainly not related to your amh work — you reproduced it with an English-only packet, and the upload stage has no per-language dependency (it encrypts the packet and POSTs it to the server; the enrolment language never enters that path). A packet sitting at Upload Packet usually means one of:

  • The packet is still at an intermediate client status and hasn’t reached an uploadable state — uploadable statuses are the approved/exported/synced set; if EOD approval is enabled in your setup, the packet must be approved first.
  • The packet sync to server succeeded but the upload call is failing/retrying — typically a connectivity issue to the packet-receiver, an expired/invalid auth (machine/operator keys), or the receiver rejecting the packet.

To pinpoint it, please check registration.log during the upload attempt for the packet-receiver call — the response code/message there will name the cause. This is really a separate topic from the Amharic thread; if the log points to a server-side rejection, it’d be best to open a new thread with that specific error so it gets the right visibility.

So: the preview font is fixed in the template, and the upload issue is a separate connectivity/status matter your amh changes didn’t cause.

Thanks and Regards,
Gokulraj C,
Team MOSIP.

17

Hi Gokulraj,
Thank You for your time and valuable inputs. I have taken over this task from Hariharan, so responding to this thread. I have already implemented the changes in the master.template table and the preview page font-rendering is working fine.

Now when I do the registration, it is not generating the UIN.

image
image1244×1200 32.5 KB

I checked the Idrepo log and found this error . “errorCode=KER-IOV-004, message=Invalid input parameter”. Attaching a snippet of the error log. What am I missing to get this error? Please advise, how can I solve this.

{“@timestamp”:“2026-07-23T07:30:44.835Z”,“@version”:“1”,“message”:“IdObjectReferenceValidationFailed: \n [ServiceError(errorCode=KER-IOV-004, message=Invalid input parameter - identity/gender/1/language), ServiceError(errorCode=KER-IOV-004, message=Invalid input parameter - identity/residenceStatus/1/language), ServiceError(errorCode=KER-IOV-004, message=Invalid input parameter - identity/province/1/language), ServiceError(errorCode=KER-IOV-004, message=Invalid input parameter - identity/city/1/language), ServiceError(errorCode=KER-IOV-004, message=Invalid input parameter - identity/addressLine2/1/language), ServiceError(errorCode=KER-IOV-004, message=Invalid input parameter - identity/addressLine1/1/language), ServiceError(errorCode=KER-IOV-004, message=Invalid input parameter - identity/region/1/language), ServiceError(errorCode=KER-IOV-004, message=Invalid input parameter - identity/addressLine3/1/language), ServiceError(errorCode=KER-IOV-004, message=Invalid input parameter - identity/fullName/1/language), ServiceError(errorCode=KER-IOV-004, message=Invalid input parameter - identity/zone/1/language)]”,“logger_name”:“io.mosip.kernel.idobjectvalidator.impl.IdObjectReferenceValidator”,“thread_name”:“http-nio-8090-exec-6”,“level”:“ERROR”,“level_value”:40000,“appName”:“id-repository”,“traceId”:“3ee7b90d417917af080b87c64b39124e”,“spanExportable”:“false”,“req.requestURI”:“/idrepository/v1/identity/draft/update/10010100080000120260723071320”,“X-Span-Export”:“false”,“X-B3-ParentSpanId”:“080b87c64b39124e”,“req.method”:“PATCH”,“parentId”:“080b87c64b39124e”,“req.userAgent”:“Apache-HttpClient/4.5.6 (Java/11.0.16)”,“spanId”:“0f75eb8bac554073”,“X-B3-SpanId”:“0f75eb8bac554073”,“X-B3-TraceId”:“3ee7b90d417917af080b87c64b39124e”,“req.remoteHost”:“127.0.0.6”,“req.requestURL”:“http://identity.idrepo/idrepository/v1/identity/draft/update/10010100080000120260723071320”}
{“@timestamp”:“2026-07-23T07:30:49.332Z”,“@version”:“1”,“message”:“IdObjectReferenceValidationFailed: \n [ServiceError(errorCode=KER-IOV-004, message=Invalid input parameter - identity/addressLine2/0/language), ServiceError(errorCode=KER-IOV-004, message=Invalid input parameter - identity/addressLine3/0/language), ServiceError(errorCode=KER-IOV-004, message=Invalid input parameter - identity/region/0/language), ServiceError(errorCode=KER-IOV-004, message=Invalid input parameter - identity/residenceStatus/0/language), ServiceError(errorCode=KER-IOV-004, message=Invalid input parameter - identity/addressLine1/0/language), ServiceError(errorCode=KER-IOV-004, message=Invalid input parameter - identity/zone/0/language), ServiceError(errorCode=KER-IOV-004, message=Invalid input parameter - identity/fullName/0/language), ServiceError(errorCode=KER-IOV-004, message=Invalid input parameter - identity/city/0/language), ServiceError(errorCode=KER-IOV-004, message=Invalid input parameter - identity/gender/0/language), ServiceError(errorCode=KER-IOV-004, message=Invalid input parameter - identity/province/0/language)]”,“logger_name”:“io.mosip.kernel.idobjectvalidator.impl.IdObjectReferenceValidator”,“thread_name”:“http-nio-8090-exec-3”,“level”:“ERROR”,“level_value”:40000,“appName”:“id-repository”,“traceId”:“7ec91458b19fa2e64b56685285e645db”,“spanExportable”:“false”,“req.requestURI”:“/idrepository/v1/identity/draft/update/10010100080000220260723072327”,“X-Span-Export”:“false”,“X-B3-ParentSpanId”:“4b56685285e645db”,“req.method”:“PATCH”,“parentId”:“4b56685285e645db”,“req.userAgent”:“Apache-HttpClient/4.5.6 (Java/11.0.16)”,“spanId”:“0cfba235c566f887”,“X-B3-SpanId”:“0cfba235c566f887”,“X-B3-TraceId”:“7ec91458b19fa2e64b56685285e645db”,“req.remoteHost”:“127.0.0.6”,“req.requestURL”:“http://identity.idrepo/idrepository/v1/identity/draft/update/10010100080000220260723072327”}

Thank you so much!

Regards,

Ranjan

18

Hi @Ranjan_mosip,

Welcome to the thread, and good to hear the preview page is now rendering correctly.

This error is a server-side validation failure, and it’s the same pattern we hit earlier in this thread, the configuration is correct at the source, but a consumer hasn’t picked it up.

What the error actually means

Note the failing paths: identity/gender/1/language, identity/fullName/1/language, and so on. The rejected element is the language attribute of each value, not the value itself. KER-IOV-004 is INVALID_INPUT_PARAMETER, so id-repository is saying “this language code is not one I recognise”, for every language-coded field in the identity object.

The two log entries are also telling: they are two different RIDs, and in one all fields fail at index 1 while in the other all fields fail at index 0. That is consistent with the amh entry being the rejected one in both cases, index 1 where Amharic was the second selected language, index 0 where it was first. English is clearly accepted, so this is specific to amh rather than a structural problem with your identity object.

Root cause

The validator throwing this is IdObjectReferenceValidator, and it does not read the language list from properties, it fetches it from the masterdata API. From id-repository’s own configuration:

mosip.kernel.idobjectvalidator.masterdata.languages.rest.uri=${mosip.masterdata.base.url}/v1/masterdata/languages

So id-repository is calling /v1/masterdata/languages and amh is not present in the response it is working with.

Please check, in this order:

  1. Call the API directly and confirm what it returns: curl <your-base-url>/v1/masterdata/languages. If amh is missing from the response, the problem is upstream in masterdata (step 2). If amh is present, the problem is a stale cached list inside id-repository (step 3).
  2. If amh is missing from the API response: verify the amh row in master.language has is_active = true, as this endpoint returns active languages only.
  3. If amh is present in the API response but the error persists: the languages list is cached, so restart the id-repository identity service pods (and the masterdata pods, to clear the cached response) so they re-fetch the updated list. This is the same class of issue as the regclient job earlier, the consumer holds an older snapshot.
  4. Check the language properties across all services, not just the client-facing ones. Please confirm mosip.mandatory-languages, mosip.optional-languages and, easily missed, mosip.supported-languages (a separate property, default eng,ara,fra) all include amh in the config that id-repository and registration-processor consume, and that those services were restarted after the change. Config-server updates only take effect on service restart.

On the stuck packets: the existing RIDs failed at the id-repo draft update stage, so they will not generate a UIN as-is. Once the validation passes, please reprocess those packets (or re-enroll) rather than waiting on them, and a fresh registration is the cleanest way to confirm the fix end-to-end.

Thanks and Regards,
Gokulraj C,
Team MOSIP.

19

Hi Gokulraj,

I updated all the language properties to ensure everywhere amh is added. Then restarted the services to clear the cache if any. Then enrolled a new registration and end-to-end flow worked fine, UIN got generated.

Thank you for your support.