I would like users in my app the ability to see the knack app in the language of their choice. For registered users I thought to add a field, interface language, into the account profile and then use the language value, once set to copy across to tables where it was being used in views.
Another way I thought about, which might be better, is to create a dedicated table dedicated to the language setting and to then use a connection field from the account profile table to the language field where this would be set.
That’s the backend, anyone have any pointers before I slog it out with trial and error
On the front end for public pages, I have already hacked together an access code, so was thinking I would add another step to the form where the first step is going to be a language select tool, the second step the access code, and the third step the form to fill in. I think that should be pretty easy.
Hey @CarlHolmes so I’ve got this down pretty well I think.
My workflow was that I added a language interface field dropdown at the account level. That account table is connected across the various parts of the setup that need to access the value.
I then use page based rules to check for the language setting and then hide-views to trigger the correct content on pages. Iterate through all the pages setting up custom views based on the language id.
A couple of minor holes are Tabbed Menu Names, as there is no way to provide a translation for that so I just have both languages.
And in the New Password field I can’t edit the label, and field value texts in the fields “password” and “confirm password”
Could you use some custom javascript to update the tabbed names?
I wonder if a different way could be a different pages per language rather than views? i say this a s some of pages have 4 or 5 views for different roles, so adding in language support for even just one , would double the amount of views on each page.
also I’m mainly commenting here so as to come back to it later as i would love the option to have languages on some of my apps.
Thanks for sharing the JQUERY page that I wasn’t aware of. Yes pages would be better, also because I think that when you have views that are set by fields the load time of those pages increase. Maybe not for something now but a version 2.00 of my app.
One thing I have noticed is that if I have a grid that has links to pages - for example links to view details or edit page within the grid. And you try and copy that same grid into the same page (for example because you then want to translate it and set a conditional view to the grid), knack has a bit of an issue and the linked pages when you go and edit them will tell you that it cannot find the scene. I have found that in these cases it is better to remove the linked pages before the copying function, and then manually add the links back in the grid to the page that it was linked to. Whether that is the view shared by the original grid or a new page, it’s better to do it this way.
An other laborious way: I have 3 same Apps for 3 languages. I copied and traduced the original.
To access the correct language App I put the embeded knack link in a wordpress microsite page for the LOGIN, repeated for each language. Than at the web site level, selecting the language will show you the corresponding link to the knack App.
What I do not like is that I have 3 non connected databases.
But with the new huge functionality of tables communication between Apps that Knack is developing, this will be solved.
Although you will end up with some pretty complex views, as long as you name them it’s pretty okay. Have an account role where you said the value of the languages with a radio field: English, German, Greek etc.
Then connect that account role to the tables which have the data that you will use in your views.
The you can create two grids, and give the grids names.
Then use a page display rule where you say
"If Account Role Language is XXXXX (language) then hide view (the view that is not the language you want to see).
