Re: Strategies for dealing with large number of languages?
All,
Same as Ralph, we've always been using a custom Translator class (since
2009/2010 or so).
so for instance .setText(Translator.translate("Submit"))
The Translator loads all labels and puts them in mem based on the language
preference of the user. So only 1 set of language labels in mem.
Works like a charm and never had a problem.
The translations are on the server side in the db so that a superuser can
manage translations.
rg,
Leon.
Op donderdag 4 januari 2024 om 09:55:26 UTC+1 schreef Ralph Fiergolla:
Hi!
Since a big part of our string content comes from database records anyway,
we decided to go without any static texts but use dynamic labels. Initial
concerns about performance and memory footprint have proven to be
unfounded. That is, despite working in the context of European Institutions
we go with a single static language and avoid the compile time performance
bottleneck of having a large number of permutations.
Cheers,
Ralph
On Thursday, January 4, 2024 at 1:29:08 AM UTC+1 Alexander Bertram wrote:
Hi there,
We have been using GWT to build our product for a very long time. Recently,
we've faced a new challenge as we've steadily been increasing the number of
supported translations of the application to support a global audience.
We're up to 24 languages, and could conceivably hit 40 in the coming year.
With all of these languages, come more permutations! We've stripped away
browser-specific permutations, but we do have a mobile version of the app,
which means that we have 2 x 24 permutations = 48.
So far, we've addressed this problem by increasing the size of the VM that
builds the app, but even with 16 vCPUs it takes 10-12 minutes to build the
app. I'm experimenting with increasing to 32 vCPUs, but so far I can't get
the build time to drop linearly.
Anyone else out there using alternate strategies? Is it worth trying to
create some sort of distributed cache from the intermediate files the
compiler writes out? Load translations dynamically at runtime instead? Or
just through more hardware at it :-)
Just curious to hear what others are doing?
Best,
Alex
--
You received this message because you are subscribed to the Google Groups "GWT
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit/40e79634-d41e-4ddb-8f5c-0d702bcbd1f1n%40googlegroups.com.
Re: Strategies for dealing with large number of languages?
The strings of our application are located on the server. At applicaiton start, the client loads the constants from the server and load it into a factory. The factory has a method that accepts a key and return the value. benefits: - no new permutations - change language without reloading the application - adding a language is just adding an new property file on the server drawback: - a little bit longer start up time - no support from the IDE Ralph Fiergolla schrieb am Donnerstag, 4. Januar 2024 um 09:55:26 UTC+1: > Hi! > Since a big part of our string content comes from database records anyway, > we decided to go without any static texts but use dynamic labels. Initial > concerns about performance and memory footprint have proven to be > unfounded. That is, despite working in the context of European Institutions > we go with a single static language and avoid the compile time performance > bottleneck of having a large number of permutations. > Cheers, > Ralph > > On Thursday, January 4, 2024 at 1:29:08 AM UTC+1 Alexander Bertram wrote: > >> Hi there, >> We have been using GWT to build our product for a very long time. >> Recently, we've faced a new challenge as we've steadily been increasing the >> number of supported translations of the application to support a global >> audience. We're up to 24 languages, and could conceivably hit 40 in the >> coming year. >> >> With all of these languages, come more permutations! We've stripped away >> browser-specific permutations, but we do have a mobile version of the app, >> which means that we have 2 x 24 permutations = 48. >> >> So far, we've addressed this problem by increasing the size of the VM >> that builds the app, but even with 16 vCPUs it takes 10-12 minutes to build >> the app. I'm experimenting with increasing to 32 vCPUs, but so far I can't >> get the build time to drop linearly. >> >> Anyone else out there using alternate strategies? Is it worth trying to >> create some sort of distributed cache from the intermediate files the >> compiler writes out? Load translations dynamically at runtime instead? Or >> just through more hardware at it :-) >> >> Just curious to hear what others are doing? >> >> Best, >> Alex >> > -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/2498f396-b504-4d3a-8e15-63936ef37b64n%40googlegroups.com.
Re: Strategies for dealing with large number of languages?
Hi! Since a big part of our string content comes from database records anyway, we decided to go without any static texts but use dynamic labels. Initial concerns about performance and memory footprint have proven to be unfounded. That is, despite working in the context of European Institutions we go with a single static language and avoid the compile time performance bottleneck of having a large number of permutations. Cheers, Ralph On Thursday, January 4, 2024 at 1:29:08 AM UTC+1 Alexander Bertram wrote: > Hi there, > We have been using GWT to build our product for a very long time. > Recently, we've faced a new challenge as we've steadily been increasing the > number of supported translations of the application to support a global > audience. We're up to 24 languages, and could conceivably hit 40 in the > coming year. > > With all of these languages, come more permutations! We've stripped away > browser-specific permutations, but we do have a mobile version of the app, > which means that we have 2 x 24 permutations = 48. > > So far, we've addressed this problem by increasing the size of the VM that > builds the app, but even with 16 vCPUs it takes 10-12 minutes to build the > app. I'm experimenting with increasing to 32 vCPUs, but so far I can't get > the build time to drop linearly. > > Anyone else out there using alternate strategies? Is it worth trying to > create some sort of distributed cache from the intermediate files the > compiler writes out? Load translations dynamically at runtime instead? Or > just through more hardware at it :-) > > Just curious to hear what others are doing? > > Best, > Alex > -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/d483e663-1aa5-4bc7-a841-0660073c8a69n%40googlegroups.com.
