i18n of end-user facing components

[dfrost999]

There were a couple of past attempts to get PRs (e.g. #2573, #7476) accepted regarding internationalization. These were all (automatically) closed though seemingly huge efforts must have gone into implementing this feature.
Is there generally no interest in having this implemented?
If I were to implement a generic solution based based e.g. on svelte-i18n, would I have a chance to get this accepted at all?
Is the "Core-Team" already working on this or is this deemed to be too-huge-of-a-change an thus will never make it into the main code base?
IMHO it would be very important to offer the possibility to translate at least the end-user facing components (the builder parts could stay English) to open up Budibase as a viable platform for non-English speaking markets and/or certain industries where native- or multi-language support for applications is mandatory.
Thanks for your consideration.

[maclm]

I totally second this. We need a minimum level of customization on the user-facing portal, like the ability to remove the "?" button and to translate it as well.

I could see this living the .../builder/portal/settings/organisation where we can already set the logo.
We could pick a portal language, customize the greetings message and so on.

Like mentioned by @dfrost999 there have been attempts in the past. Now that you've reached V2, is this on a road map somewhere?

[juliencognet]

+1, this is really important to have a consistant user experience

[tk-subgenius]

I immediately stopped using this product when I saw it doesn't support localization. Strange it was not handled from the beginning, i8n is a standard feature of so many apps.. It's a pity because it seems so powerful otherwise.

[jamap]

Guys...

I'm using Pontoon for internationalization and created a customized view in order to give me the results (a view from Pontoon DB that returns LocaleCode; OriginalString & Translated String. I'm including the LocaleCode as an additional column in User Table and my idea is to fill the "labels" of the fields with the translated String using the LocaleCode (from user) and OriginalString from component Name as filters.

However I'm facing difficulties to do the Query to get the information and return it back to the label. Any idea of how can I do that?

BR's

José Armando Porto

[melohagan]

Hey @jamap

I'm not familiar with Pontoon DB. Would you be able to share some screenshots as I'm not quite visualising what you are trying to accomplish.

[jamap]

Hi Mel Let’s try to get it simple… I already did a view on Pontoon DB in order to simplify the result. The query has the following result:  So, my idea is to get “locale_code” from a field “locale” that I will include in user table and query the budibase component name against original string, returning the translatedstring assigning this to the label of budibase component. I was thinking about an alterative approach that is on page load put a code that goes through the collection (if available) of all budibase components and for each one changes the label to the translatedstring content wherever we have this budibase component name in the original string. If we do any of this I solve my problem. BR's

…

On 29 Mar 2023, at 09:45, melohagan ***@***.***> wrote: Hey @jamap <https://github.com/jamap> I'm not familiar with Pontoon DB. Would you be able to share some screenshots as I'm not quite visualising what you are trying to accomplish. — Reply to this email directly, view it on GitHub <#9346 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADFZM7GD7KNUFTDTW2K7G63W6QVHRANCNFSM6AAAAAAT33XO7Y>. You are receiving this because you were mentioned.

[jamap]

Here is the screenshot.

BR's

[melohagan]

Thanks @jamap

In that case, I would use a filter on a Data provider.
locale_code EQUALS Binding: {{ Current user.LocaleCode }}

And your component tree would look something like so:

Data provider (filtered)

Country paragraph
State paragraph
City paragraph

Then for each of the paragraphs, they would have unique bindings, such as this one for country:

return $("Data provider.rows)?.find(row => row.originalstring === "ClientCountry")

---

This locale table scenario would be a little easier if the originalstring values were themselves columns. E.g. a table formatted like so:

locale_code	ClientCountry	ClientState	ClientCity
en-US	Country	State	City
pt-BR	Pais	Estado	Cidade

because then it would be a simple matter of doing this:

Repeater block (filtered on locale_code -> only one row returned)

Country paragraph (bound to: {{ Repeater block.ClientCountry }}
State paragraph (bound to: {{ Repeater block.ClientState }}
City paragraph (bound to: {{ Repeater block.ClientCity }}

[jamap]

hmmm... Seems you did not get the problem I want to tackle.

this is an example of output. I may have thousands of the originalstring bound to tenths of locale_code. This makes the approach of putting originalstring as columns unfeasable.

But, even if this approach would work, can you please show me how to bind this to the LABEL of the screen components? Are you proposing that I consider a different paragraph for each component and bind this paragraph to the content? As far as I understand If I do this It would not be possible to the actual table and/or API that I have to bind.

BR's

[melohagan]

This makes the approach of putting originalstring as columns unfeasable.

That's fine, in that case you would follow the first example where you find the specific key from the returned rows.

To clarify, do you mean label of form inputs, such as Text fields?

[jamap]

Yes...

The point is to change the screen visible output (not just forms) perceived by the user that we define at component's properties in order to show it in the user locale language without the need of doing different applications for each language.

I already thought about doing a loop through all components (forms, texts, whatever...) in a given screen at OnLoad event doing this adjustment but did not found where to put this on Screen Load nor how to work with an specific datasource that would be used only at this moment (Load).

Any idea?

[leolivier]

Hi, don't know why this conversation stopped but I'm also very interested in answering this as I'm trying to build a multi lingual app with budibase.
I saw that the label in "manual forms" can be customized through a javascript script so the approach above can be done (although it doesn't work in generated table or grid blocks so you need to eject them to be able to customize the labels).
But @melohagan suggested to use the locale of the current user and I don't see any locale in the user data (and you can't add new columns)... Furthermore, it would probably be better to use the locale of the browser...
I can get the browser locale in javascript but I wonder haw I can create a filter with that?

[julrichkieffer]

Perhaps, rather than the data-based approach (illustrated by @jamap above), this could be raised to the design / screens / app level, where the concern is best met -- in the UI. This is because several considerations are not (and cannot be) addressed by the data approach:

1. User agents (browsers) have a prioritised set of locales: {en-GB: 0.98, en-US: 0.95, en-ZA: 0.91, en: 0.9, es: 0.8, de: 0.5}
2. Plurality is locale specific: Russian has several forms whereas English has 2 plural forms only: 1 versus [0, 2+]
3. Locales may drive tone and interpolation sites within strings (see translatedstring is only a literal value)
4. Budibase already supports expressions for values; it just needs to afford the same to labels OR have locale-driven apps / screens where the existing field labels / table headers / button captions / tooltips / placeholders can be hardcoded as present, but presented as locale-specific screens to the user. There's a significant duplication & syncing tradeoff here, but it's a marginal increase on existing features.
5. Conversely CSS and browsers' dynamic layout already support these suggestions, yet Budibase doesn't. For example, RTL and Hebrew / Arabic / Japanese fonts (also prioritised as 'font stacks' in CSS) are readily avilable should Budibase adopt RTL etc. screens.
6. User agents may provide supported locales (see 1) but the app developer / logged in user may want to limit / specify their UI's supported locale(s): {en, de, fr}. So extending the Budibase Users (data) to include user (profile) preferences. For example, if no specific locale set, then the user agent's priority is tested against developer-set supported locales -- a 3-way matching.
7. Custom UI components must be indistinguishable from Budibase standard components. UIs must be translate-able in their entirety regardless of component author / release / translation cadence, yet fallback to the developer's original label as default rather than error or omit a label, etc.

As you can see, data won't address these runtime / presentation considerations unless the app-per-locale suggestion (see 4) is adopted, ushering in several discouraging tradeoffs. Moreover, an approach is needed to ensure dates, currency, currency precision (eg UAD 1.015 is 3 decimal precision rather than 2 whereas other locales may have 0 decimals), aforementioned plurals vs singulars, abreviations, letter spacing, and wrapping all differ across locales. And then an approach is needed for actually capturing and maintaining the translations as apps are published versus revised over time -- one where lay users -- not developers -- can be leveraged to maintain UIs. (I trust a Tronto native to translate English into the tone, grammar and plurality of Norwegian better than interpolated strings sourced via AI, for example. It would suit a crowd-funding / open source-type approach to have lay users be the translators for their app's UI).

NOTE: It's more urgent that end-users are offered UIs in their preferred locale(s), but eventually the Budibase administrative UIs should follow. For example, to be an English developer building apps for a UAE-based customer and user population: develop and admin in English, but publish to Arabic / Japanese / Hebrew users who read and capture in their best-calculated UI -- see all above.

Perhaps start with locale-specific app screens and RTL? (It's 80% of the solution via 20% of the devX, but we have to start from a known good)

1. Each screen might have a new LTR / RTL toggle setting
2. Instead of labels being "hardcoded" with the column names from the underlying table, these should be defaulted to an expression e.g. T["dataColumnName"] or P[T["dataColumnName"], 1]

Here the following pseudocode is suggested for this:

• T[key: string] is a dictionary accessor where key and the matching algorithm above either finds a locale-matching string, or the key value itself is returned. That is, a value is always returned (for presentation in the screen).
• T[key: string] may return interpolation sites eg. No rows found versus {0} rows found, and thus pluralisation is relevant.
• P[key: string, value: any] is a dictionary accessor where key and the matching algorithm above either finds a locale-matching string, or the key value itself is returned. That is, a value is always returned (for presentation in the screen).
• P[key: string, value: any] may resolve some or all interpolation sites by binding to the value parameter, eg P["{0} rows found", 1] => 1 row found. However, a "currying" behaviour should emit the unmatched interpolation sites to allow P[P[P[]]] chaining. For example, P[P[C[T["automationSummary"], "฿", 1.045], 150], 256] => Of the 256 pending transactions found, 150 invoices were generated totalling ฿1.045.
• C[key: string, symbol: string, amount: number] would handle currencies, D[...] dates, F[...] floating precisions, etc would all be helpers that wrap and chain discrete internationalisation utilities. Using the existing utilities means a marginal increase to an existing working approach, and allows javascript and handlebars interoperability at the UI / screens level.

TIP: Inspired by OrchardCore CMS's Localisation feature

[leolivier]

I fully approve what you're writing here @julrichkieffer but as it does not look like it's on BB roadmap, I was trying to find a kind of workaround =o)