Forum Discussion
I have had this question on my todo list and wanted to get my answer in before leaving for Empower. I actually think this is doable with Service Workers. and if I have enough time I might even create a demo of how I would approach this.
Normally, when an application supports multiple languages there have to be explicit design provisions made for all the language strings used throughout the application to be identifiable and stored in some type of language catalog which can be changed easily. This certainly isn't the case with QuickBase. The various English language strings used are just randomly tossed into the HTML, JavaScript and data in a wide variety of ways.
For example, the language strings might be hard-coded into the page's HTML source, introduced through templates, hardcoded into JavaScript strings etc. So an initial analysis of this problem might proceed by enumerating how (1) the English language strings are technically introduced into the application and (2) what role the user is in (admin versus general user) to determine the scope of which pages will receive language translation.
For example consider the language strings that show up on administrative pages as one category:
And consider consider as another category those language strings that show up in various dialog, warning and error messages:
You could continue in this fashion and probably come up with perhaps a dozen different categories of language strings based on the nature of the strings and where and how they show up.
However they show up a Service Worker could be created that would examine the existing page before is is handed over the the browser for rendering and make the necessary changes. This may sound boastful but technically this is one of the things that a Service Worker can do. The reason you would have to identify what category the language strings are in is because a variety of different technical approaches wold be needed to make the language string substitution in script. The might be a 100 of language string substitutions needed on some pages and this would add to the processing time.
I should note that if this was a designed in feature to the product there would be a much more efficient way to directly generate pages with the correct language strings and there would be no substitutions step involved. However, you would still have to go through the analysis of what all the categories of languages strings are so this would be a useful exercise in itself.
I know this procedure of substituting language strings through a Service Worker may sound outlandish but I do think it is technically possible and there probably is some sweet point of 80% coverage where non-English users could get a big assistance using the approach.
I think I am going to try and come up with a demo if I find time before I leave for Empower.
Normally, when an application supports multiple languages there have to be explicit design provisions made for all the language strings used throughout the application to be identifiable and stored in some type of language catalog which can be changed easily. This certainly isn't the case with QuickBase. The various English language strings used are just randomly tossed into the HTML, JavaScript and data in a wide variety of ways.
For example, the language strings might be hard-coded into the page's HTML source, introduced through templates, hardcoded into JavaScript strings etc. So an initial analysis of this problem might proceed by enumerating how (1) the English language strings are technically introduced into the application and (2) what role the user is in (admin versus general user) to determine the scope of which pages will receive language translation.
For example consider the language strings that show up on administrative pages as one category:
And consider consider as another category those language strings that show up in various dialog, warning and error messages:
You could continue in this fashion and probably come up with perhaps a dozen different categories of language strings based on the nature of the strings and where and how they show up.
However they show up a Service Worker could be created that would examine the existing page before is is handed over the the browser for rendering and make the necessary changes. This may sound boastful but technically this is one of the things that a Service Worker can do. The reason you would have to identify what category the language strings are in is because a variety of different technical approaches wold be needed to make the language string substitution in script. The might be a 100 of language string substitutions needed on some pages and this would add to the processing time.
I should note that if this was a designed in feature to the product there would be a much more efficient way to directly generate pages with the correct language strings and there would be no substitutions step involved. However, you would still have to go through the analysis of what all the categories of languages strings are so this would be a useful exercise in itself.
I know this procedure of substituting language strings through a Service Worker may sound outlandish but I do think it is technically possible and there probably is some sweet point of 80% coverage where non-English users could get a big assistance using the approach.
I think I am going to try and come up with a demo if I find time before I leave for Empower.
