We recently deployed a German language pack (de_DE) in our Blue Yonder Luminate distribution environment (2022.2), and everything seemed fine during the language pack import process. Users can see German labels in the UI, but we’re hitting a critical issue with printed picklists.
When warehouse staff print picklists, all the custom field labels are showing as key codes (e.g., CUSTOM_PRIORITY_LEVEL instead of “Prioritätsstufe”). The standard fields display correctly in German, but our customized fields are broken. We verified the label key mapping in the language files looks correct:
<entry key="CUSTOM_PRIORITY_LEVEL">Prioritätsstufe</entry>
<entry key="CUSTOM_HANDLING_NOTES">Handhabungshinweise</entry>
This is blocking our German warehouse from processing orders efficiently. Has anyone dealt with print template localization issues after importing language packs? Do we need to rebuild the localization cache or update print templates separately?
The print service has its own resource bundle cache that’s separate from the main UI cache. After language pack deployment, you need to refresh both. Go to System Administration > Localization Management and run the “Rebuild Print Template Resources” utility. This forces the print service to reload all label mappings from the newly imported language packs. Also verify your language pack XML includes the print-specific resource bundle entries, not just UI labels.
This is a known issue with custom field localization in print templates. The problem is that print templates don’t automatically pick up custom label translations after language pack import - they need explicit refresh. Check your print template XML files in the distribution module configuration. You’ll probably find they’re still pointing to the base language resource bundle. The localization cache rebuild is definitely needed, but you also need to verify that your print templates are configured to use the localized resource keys properly. What’s your current print template setup?
Thanks for the responses. Our print templates are using label key references, not hardcoded text. I checked the template XML and found references like ${label.CUSTOM_PRIORITY_LEVEL}. We did restart the application servers after the language pack import, but didn’t explicitly rebuild the localization cache. Is there a specific command or admin function to force the cache rebuild for print templates?
I’ve seen similar behavior with custom labels not appearing in reports after language pack updates. The print templates might be caching the old label references. Have you tried clearing the application cache and restarting the print service? Also check if your print template definitions are using the correct label key references versus hardcoded text.