Re: Strategies for dealing with large number of languages?
Thanks!
This is all very helpful.
Following on what Collin suggested, I took a look at what the effect would
be of collapsing all the permutations.
I found that collapsing all 23 languages into a single permutation would
increase the gzipped initial download of our application from 443k to 633k,
which is not a good tradeoff for us as many our users are working in areas
with poor or limited connectivity. But there is a probably room to group
2-3 languages together to reduce the number of permutations in the
short-term.
Also, I did some experimenting with virtual machines, and for what it's
worth, moving from n1-highmem-32 to c3d-standard-8 cut our build time in
half, and is much much cheaper. The C3D, which is based on AMD's Genoa
processor seems to do better than the corresponding Intel-based C3 (and is
cheaper).
However, long-term, it sounds like using side-loaded dictionaries are both
feasable and much more practical. We'll start investigating how we can make
the change this year.
Thanks again, and all the best for 2024.
Alex
On Thursday, January 4, 2024 at 2:16:24 PM UTC+1 Leon Pennings wrote:
> 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/6cdd1d45-7f03-4ed0-88b9-f878cec84e09n%40googlegroups.com.
Strategies for dealing with large number of languages?
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/9713894e-f5e5-4603-9481-76752ccd199en%40googlegroups.com.
Re: GWT Java Full Stack Developer Job
To pile on the thread, we also have an opening for a developer position with a very important GWT component. We are a small software firm based in the Hague, the Netherlands, that develops a niche database software, ActivityInfo, used by UN agencies and NGOs in more than 60 countries to collect, manage, analyze data. Think of a very user-friendly version of Microsoft Access, but web-based, with offline synchronization. We have been using GWT from the start, since 2008, but in 2019 completed a full rewrite of the codebase that kept GWT, but shifted towards a functional reactive user interface built on a GWT port of Preact and more GWT-friendly version of RxJava instead of widgets. It works really well for reliable, complex user interfaces like our form designer, spreadsheet importer and more. To meet the needs of our users, we have our own query engine that runs both on the server, using Google Cloud Datastore as storage, in the browser, backed by IndexedDB, and on our on-premise version where Sqlite is used for storage. We're looking for someone to join our team to help build new features, particularly in our data analysis and visualization toolset, fix the edge-case bugs our users run into, and continuously improve performance and usability. We have a great CI/CD setup, release several times a week, and get great, direct feedback from our users in Yemen, Afghanistan, Ukraine, everywhere else. Full job post is here: https://www.activityinfo.org/about/careers/software-engineer.html We anticipate fully remote, would be nice if you are close to the European timezone. If you're in the Netherlands, then we can offer you a nice office as well. Thanks! Alex On Friday, May 27, 2022 at 2:01:03 AM UTC+2 Thomas wrote: > Yes, in the reply above. > > -- 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/64519726-bf86-4b6e-bf30-9d05ade06eadn%40googlegroups.com.
Re: Our 10+ year journey with GWT (+ job opening)
Nice to hear from everyone! Here's to the next ten years :-) Best wishes for 2021, Alex On Tuesday, December 22, 2020 at 10:22:08 AM UTC+1 Segun Razaq Sobulo wrote: > > I've been using GWT for 7+ years (with appengine java backends) and > actively looking for a job. I'll push my resume. > > Thanks > On Monday, 21 December 2020 at 15:24:19 UTC+1 aka...@gmail.com wrote: > >> We are in times where working remotly id actually a good option. >> >> On Monday, December 21, 2020 at 4:19:13 PM UTC+2 David Nouls wrote: >> >>> Hi Alex, >>> >>> Same story here. I have been working with GWT since it first came out. >>> For our current project we again opted for GWT because we share a lot of >>> code between client and server and productivity is high. >>> >>> I’m not available at the moment (maybe end of next year)… but living in >>> Belgium/Leuven I don’t think that is doable. Relocation is not an option. >>> Good luck finding people, there are not a lot on the market. >>> >>> Groeten, >>> David >>> On 20 Dec 2020, 16:16 +0100, 'Alexander Bertram' via GWT Users < >>> google-we...@googlegroups.com>, wrote: >>> >>> >>> Dear all, >>> >>> I hope this email isn't too off-topic, but I wanted to share an opening >>> for a job on our team with a large GWT component. >>> >>> https://jobs.bedatadriven.com/software-engineer >>> >>> The first version of our product, ActivityInfo, a data collection and >>> analysis platform for humanitarian relief, was built with GWT, GXT and >>> Google Gears in 2009 and seriously would not have been possible without >>> GWT. >>> >>> In 2018, nearly 10 years later, we looked at the amazing js ecosystem >>> and considered moving to Typescript or Elm. >>> >>> Instead, we decided to keep the bits that we loved about GWT: the >>> typesafety, code-reuse with the server, i18n, code splitting, linkers, and >>> the amazing compiler, and add SCSS for styles and our own port of Preact + >>> rxJava-like reactivity for dom manipulation using Elemental2. >>> >>> Three years after the start of ActivityInfo 4.0 we couldn't be happier >>> with the choice, and are more productive than ever. >>> >>> If you're an experienced GWT developer that would enjoy the challenge of >>> a working on a modern GWT codebase, I hope you'll consider joining our team! >>> >>> >>> 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-tool...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/google-web-toolkit/46240bd9-f716-4448-a481-acfc87229f8fn%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/google-web-toolkit/46240bd9-f716-4448-a481-acfc87229f8fn%40googlegroups.com?utm_medium=email_source=footer> >>> . >>> >>> -- 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/aef7519b-7bcf-468e-8147-6c287a76565dn%40googlegroups.com.
Our 10+ year journey with GWT (+ job opening)
Dear all, I hope this email isn't too off-topic, but I wanted to share an opening for a job on our team with a large GWT component. https://jobs.bedatadriven.com/software-engineer The first version of our product, ActivityInfo, a data collection and analysis platform for humanitarian relief, was built with GWT, GXT and Google Gears in 2009 and seriously would not have been possible without GWT. In 2018, nearly 10 years later, we looked at the amazing js ecosystem and considered moving to Typescript or Elm. Instead, we decided to keep the bits that we loved about GWT: the typesafety, code-reuse with the server, i18n, code splitting, linkers, and the amazing compiler, and add SCSS for styles and our own port of Preact + rxJava-like reactivity for dom manipulation using Elemental2. Three years after the start of ActivityInfo 4.0 we couldn't be happier with the choice, and are more productive than ever. If you're an experienced GWT developer that would enjoy the challenge of a working on a modern GWT codebase, I hope you'll consider joining our team! 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/46240bd9-f716-4448-a481-acfc87229f8fn%40googlegroups.com.
