Requesting a comprehensive review of localization issues

[Kirk_Masden]

I have a specific request regarding localization that I will describe below. Before that, however, I would like to point out that there have been many requests for small improvements in localization. Some of these requests have been answered (thanks!) but many remain unaddressed. I think that AppSheet may tend to look at the number of votes for localization requests and get the impression that because the number for individual types of localization are small, not many creators need these changes. That, of course, is a problematic assumption because we only have a limited number of votes. Also, as the AppSheet platform because increasingly international, I think it should be clear that the need for improved, more comprehensive localization will continue to grow.

My proposal to colleagues such as @Fabian , @Steve_Fuller , @tsuji_koichi and others who have expressed an interest in improved localization is to unite and form a “localization” union! I’m half kidding but half serious. I think that if we make separate, individual requests for incremental improvements in localization, it’s going to take a very long time to get major improvements. If, however, everyone who is interested in making multilingual apps or apps that adjust easily to the location of linguistic choice of the user can come together behind one request (this one?) we have a better chance of getting AppSheet’s attention. If you agree and you think this request that I’m making is OK for that purpose, please vote for this and ask your multilingual friends to vote too.

Now, here are some examples of other related requests that have been made:

Localize for "Local changes have not been synced. Proceed anyway?" Questions

[image] This message will Pop Up for example when you leave your actual App via LINKTOAPP() and still have changes to be synced.

Localize for "Accept" Feature Requests

Please enable Localization for “No” and “Accept” in the app use consent page. [image]

Localize for "App Gallery" Questions

I would like to translate the term “App Gallery” via Localize. [image]

Localize for "App Gallery" and "Add Shortcut" Feature Requests

In Menu we have “App Gallery” and “Add Shortcut”. I would like to translate them in my Language. [image]

Localise Confirmation Messages Feature Requests

In the Copy Action we can set the Display name dynamically to adjust for a User Setting for Language [Screenshot 2019-12-18 at 14.31.29] However, the confirmation text is not dynamic. [Screenshot 2019-12-18 at 14.31.41] Any chance this can be changed?

Address type fields to localize the address value displayed as option Feature Requests

Address type is useful and give the list of options for address value as we keep typing in the value into the field. (Assuming Google Map API coud be running in the backend…) It is clever enough, but it is also troublesome as it is always converted the address to English all the time. For instance, I type address in Japanese, then tooptips with address value pops up below the fields, it is picking up the right address value, but it is in English terms all the time. User should expect the opt…

And here’s the specific issue I noticed today:

We are able to localize (choose the language for) “About” in the side menu. However, we are not able to use expressions to make adjustments to Info → Properties → Information for App Users, which controls what will be shown when the user taps on “About.”

UX → Localize, however, does allow such expressions. Please make it possible for us to use expessions in Information fo App Users in the same way. I have two reasons for requesting this. One is that my app is bilingual and I would like to choose the language according to the setting. The other is that I want the “About” menu to direct the user to another part of that app, but the location can be changed using settings I have made for the user so I want to be able to make the message adjust automatically using and expression.

Thanks!

[Rafael_ANEIC-PY]

Larga vida to the localization union ! It would be nice to have complete localization control for our apps, so our users don’t find half translated sections of it.

Also, i just had a funny idea

Localize for "Accept"

Please enable Localization for “No” and “Accept” in the app use consent page.

If they add a localization option for this screen couldn’t i just swap “No” for “Yes” and “Accept” for “No” just to mess with my users? just kidding, i don’t want to be fired hehe

[Kirk_Masden]

Thanks! It looks like we are a union of two at the moment. Hoping for more joiners.

I think I saw something about ACCEPT when I was looking through previous localization requests but I may be mistaken. At any rate, AppSheet is becoming more and more flexible over time. I just hope lots of the localization variety of flexibility keeps increasing.

By the way, I think that “localization” should be an important keyword in this community but a search for “localization” also pulls up posts with “local.” I wish we had a way to limit searches within this forum to exact matches but, unfortunately, I don’t this we have that capability yet.

[Fabian_Weller]

Still waiting for this:

App use consent --- new feature for all apps (privacy and compliance) Announcements

FYI, sometime in the next week, we’ll be introducing the ability to localize or modify the content of the consent dialog. This will be via the UX -> Localization tab as always.

[Kirk_Masden]

Thanks @Fabian ! I’m slightly concerned about the emphasis on the localization tab, @praveen. As I wrote above, the issue that prompted me to post was “Info → Properties → Information for App Users” which displays information in the about menu. We can write in any language we want here, but just one language – no conditional expressions. So, one app can’t be truly multilingual.

Actually, this “About” spot in apps functions like a detail view in our apps. If we could be given a way to override the default “About” and make our own view to replace it that would solve the problem.

Another problem with “About” is that it is not at all WYSIWYG. This is another respect in which I think that the “Information for App Users” may need some redesign.

One more point: The “Information for App Users” assumes that additional documentation will be put on the web. I, however, have been all of my documentation into my app. Lack of expression functionality in Info → Properties → Information for App Users makes it impossible for me to use an action or link to direct users to the in-app documentation.

Here’s the “About” documentation:

help.appsheet.com

Customizing the About Page

Every app has an "About" page that describes the application: here's how to customize it.

There doesn’t seem to be away to replace it – just modify the wording in the various categories.

[pravse]

@Fabian wait no longer :]. You can also disable or enable the user consent dialog entirely.

[Kirk_Masden]

Hi @praveen ! Thanks for your response.

I just found your explanation about how to disable the consent dialog:

App use consent --- new feature for all apps (privacy and compliance) Announcements

It took a while to get this done, but finally you can also disable or enable the user consent dialog entirely (look for the option in the Security → Options pane), but it is on by default. And you can localize its contents via the UX → Localization pane.

Also, I searched in AppSheet documentation for “properties” but couldn’t find an overall explanation of the various “properties” options:

I’m having trouble figuring out what will be displayed where. Is there a comprehensive guide to the various categories of text (where each will be displayed, etc.)?

[Koichi_Tsuji]

Should be this one, Kirk.

[Kirk_Masden]

Thanks! I found it after I saw Praveen’s comment on the “Announcements” post.

[Fabian_Weller]

Kirk_Masden:

I’m having trouble figuring out what will be displayed where.

Hi @Kirk_Masden Please see here:

App use consent (privacy and compliance) in other languages Tips & Tricks 💡

It’s not possbile to translate the message, the users see when they open an App first time. [image] But we can use some fields under INFO --> PROPERTIES to enter our own info in our own language. These are the fields that will show up: Under APP PROPERTIES Short Name Short Description Description Under INFORMATION FOR APP USERS User Guidance This will look like: [image] In “User Guidance” we could enter something in our own language like “Please press ACCEPT to use the App”.

[Kirk_Masden]

Thanks! I think you are referring to this explanation:

I agree that it’s useful. I also figured that out through trial and error. (I should have looked at your post first )

In addition, I can say share that “Purpose” and “Design Details” (under “App Documentation”) will not be displayed inside the app.

They are displayed in the page created for the app as a sample (the first paragraph is “Purpose” and “Design Details” is displayed in “How we built this app”):

It would be nice to have comprehensive documentation about where such text is displayed.

Finally, in regard to how to access the dedicated web page for a single app that you have made public, I got this good explanation from @tsuji_koichi :

Why is the appGuidString used in error messages? Questions

Just simply URL of https://www.appsheet.com/samples?appGuidString=xxxxxxYOURAPPIDxxxxx this url will open the app IF you set the app is NOT requiring the sign in, regardless that the app is prototype or deployed. Even we dont need to SAMPLE APP setting ON… Probably you may know about this, Kirk san.

If you have a portfolio page with sample apps, and are logged in with the same account you used to make the apps, clicking on the sample apps will take you to the editing interface, not the dedicated page for that app. In order to access the page (to check, for example, that it looks OK), you need to follow Koichi’s advice.

I hope this too can be documented properly. I’ve been using AppSheet for over four years and I only just found out about this. Some aspects of this no code platform are surprisingly difficult to figure out.

[Fabian_Weller]

Some other things we cannot translate:

Multilingual Starter App w/ support for 106 Languages Announcements

Hi again! The semester has just ended in Japan and I now have a bit more time to work on my app. I’ve been enjoying customizing my menus but have noticed a few minor issues with linguistic customization: We don’t seem to be able to translate some system messages. [Screen Shot 2020-08-06 at 15.43.28] This is not a big deal but if part of the idea is to avoid displaying messages that some users may find unsettling because they are unable to interpret them with confidence, more complete abili…

Feature: Changing the language in your app (localization) Tips & Tricks 💡

Localization is very very useful, but a few words are missing or just i didnt find it… ‘Release to sync.’ ‘Pull to sync.’ ‘Last updated … ago.’ ‘Terms’ ‘Privacy’ ‘Licenses’ ‘Version’ [image] [image]

[Kirk_Masden]

When I originally wrote this post I was primarily interested in improving localization within apps we build on AppSheet.  Since then, however, I have come to feel the need for localization of the platform itself.  Specifically . . .

• the AppSheet app, which is always in English, regardless of the user-selected device language, until you begin "playing" an app into which you have build
• the AppSheet editing interface, which is also always in English, regardless of the language preferences in your Google account

I am a native speaker of English so the fact that everything in the Google platform is in English is not a problem for me personally.  However, it does make it harder to introduce the platform to Japanese people who are not fluent in English.  

I'm prompted to post this comment in this thread because of discussion here:

https://www.googlecloudcommunity.com/gc/Tips-Tricks/Feature-Changing-the-language-in-your-app-locali...

Since the title of this feature request is "Requesting a comprehensive review of localization issues" I thought I'd include my request for a look at localizing the AppSheet platform itself here instead of posting a separate feature request.