snorkie wrote:We're getting pressure from one of our customers to internationalize our software product
Basically if you want to sell in France and/or Quebec (Canada) you better be able to support French.
snorkie wrote:One of the devs wants to remove the resx files and put all translations in a database table (actually 3)
Certainly not something I would want to see happen.
The UI is going to just end up caching that every single time. What happens if someone does a browser refresh? Do you load each page or everything all at once? If you have 1,000 distinct text items on a new page do you really want to do a pass through cache (1,000 separate database calls.)
There would of course be process (not code) considerations for how it gets into the database during normal feature deliveries. Does it end up being treated as a database update which means there are also rollback considerations if a feature fails?
Same consideration applies to all non-prod boxes also such as Developer and QA.
What happens if the if the database is down?
I think the 'dev' that wants this should be required to write the conversion Epic along with all of the stories and designs needed to support it. Then cost it out and present that, the cost, to management. I suspect that will be nixed by management even presuming the 'dev' has the willingness and expertise to fully write out the plan. It should include at a minimum.
- Specific analysis of why this is better.
- How UI uses it. Specifically what needs to change in the UI.
- Performance impacts
- Deployment steps for changes
- Removing the old code.
- How this will be supported with current translation service.
snorkie wrote:There are also some database translations where we allow customization.
Presumably a customer can change this. That should not be a consideration for this case. However if a customer wants to support users with different language needs does that existing design account for that?