[Isomorphic]

You referred to a field name change again, but we think you actually meant field title again, right?

So to be clear on what you're asking: you're expecting that localized field titles change at runtime, even within the same locale? And this is why - because translations were actually added or updated for a locale?

Do you realize that, even if new titles are available at the server, the application loaded into the browser won't change: the user will have to reload the page, and depending on how things are configured, browser caching may mean they still see the older version of the DataSource, even on reload?

Just seems odd that you would bother making things this dynamic. A web application restart doesn't take very long, and the UI can handle the process very smoothly. Depending on how sessions are implemented, users that don't happen to make a request during the restart may not even notice that it happened.

[Blama]

Hi Isomorphic,

You referred to a field name change again, but we think you actually meant field title again, right?

My bad, always meaning field title.

So to be clear on what you're asking: you're expecting that localized field titles change at runtime, even within the same locale? And this is why - because translations were actually added or updated for a locale?

This is my plan of action:

• Reduce my WAR-file count to the minimum number possible in 11.1/12.0 - that is a combined war for every customer that can live with the default field names plus one for every customer with special needs
• Reduce my WAR-file count to 1 in 12.1p
  • Introduce suffixed DataSources
  • Use LocaleMessageProvider
• Restart the application only if a new customer is onboarded or an application update is made

This means if I onboard a new customer and he or she changes the field titles, this change should be visible immediately (=meaning after a reload with a cache buster for DataSourceLoader (already have it for .ds.xml changes, just need to amend it)).
Most likely I'll have to restart the server to make it also serve the new customer's subdomain, but once it does and the user has the Admin account, he or she should be able to change field titles.

Do you realize that, even if new titles are available at the server, the application loaded into the browser won't change: the user will have to reload the page, and depending on how things are configured, browser caching may mean they still see the older version of the DataSource, even on reload?

Yes, reload is fine and I can display a message "Please reload after doing changes to the titles in order to see an effect". But I can't display a message "Please wait until I choose to restart the application server".

Just seems odd that you would bother making things this dynamic. A web application restart doesn't take very long, and the UI can handle the process very smoothly. Depending on how sessions are implemented, users that don't happen to make a request during the restart may not even notice that it happened.

Yes, your relogin mechanism is indeed pretty amazing :)

The only problem here if it were cached is that it's hard to tell for the customer when a change will come live and this is strange.

Best regards
Blama

[Isomorphic]

OK the new piece of information here is that the customers themselves are actually updating your translation packs. That is very, very odd. Are we again talking about *localization* here or *customer-specific terminology*. Because again, in the former case, caching makes a lot of sense. In the latter case, it doesn't, and neither does asking each customer to translate generic phrases into their own language.

Handling the latter via localization is a hack.

[Blama]

Hi Isomorphic,

Ah, ok. Sometimes it takes really long via written messages until both participants have the same understanding.

It's customer-specific terminology. But once I use suffixed DataSources per customer, this should not matter for the framework, or does it?
I mean where is the difference if I translate Reseller to "Händler" or "Vertreter" - both are just strings.
The only thing different is that I already provide a default translation that one can use or overwrite.

I agree that the setting is very very odd, but we are not in the position of some big CRM vendors to dictate terms (no pun intended).
Also, the customer group we are targeting the most often has reluctant Partners/Resellers/Dealers/Brokers that sometimes are not very computer savvy and was just used to work with Excel (or even pen and paper) before.
So the application has to be dead easy for them from usage and wording.

Handling the latter via localization is a hack.

That is why I asked here

OK, but what would be an non-hackish solution worth the necessary effort to the task in your opinion, if the application is the same otherwise?

Best regards
Blama

[Isomorphic]

At the risk of sounding like a broken record: it's not reasonable to expect no caching of localization. Translations to other languages do not normally change. If a language pack is updated by the application designer, it's reasonable to restart the server to get the new translations.

Industry-specific or customer-specific terminology, especially if updated *by the customers themselves*, is a totally different thing. It makes sense that it might change at runtime.

When you try to achieve industry- or customer-specific terminology via a system designed for localization, that's a hack, and you should expect it to break. There doesn't happen to be caching right now, but we cannot commit to never implementing caching strategies that would be perfectly reasonable in the context of localization, but would break your use case of customer-specific terminology.

[Blama]

Hi Isomorphic,

all understood. And good to know that it works now (or, more specific, with 12.1). I assume that you would not introduce changes here in a nightly, but only in new major or minor versions, correct?
Also good to know that you say that if the caching is enabled at some point in the future, a server restart would be sufficient to pick up the right string (=cache would be per (suffixed) DataSource+fmt-String, not just fmt-String only).
In this case we would only loose live editability, which is not good, but also not as bad as a fallback to default strings or a random whatever-gets-requested-first-and-cached result.

But given the fact that you built the feature for us and that the thread mentioned "slightly different terminology" as use case already in the 1st post, I assume that you would also build a possibility to disable the cache, correct?
This would then be perfectly fine or me, as the strings will come from the DB and I'll implement an application-side cache there.

Finally I think it is good for all users to have a list of points to watch out for in a SmartGWT based SaaS / Multi-Home product here in a single thread. Do you think it would make sense to extract the relevant points here in a docs entry, perhaps linked from the Quick Start Guide?

Best regards
Blama

[Isomorphic]

The only scenario in which we would add a cache here in a release version would be if we found it was creating a performance problem bad enough that it is rightly regarded as a bug. Seems extremely unlikely here.

If caching needs to be added, we can add a flag to disable caching.

[Blama]

Hi Isomorphic,

perfect, thank you.

Best regards
Blama