Blinks Language Localization

sRFC
1

Blinks Language Localization

Adding Language code to requests for localizing texts

Localizing texts to the user’s preferd language gives a better ux, plus it facilitates onboarding non-english speakers.

Since the text of stuff is rendered on the server side, there are two ways we could have it done:

  • The client tells the server what languages does the user’s computer has
  • The server sends different JSON paths for every language it supports, and the client picks the one that matches the user’s browser setting

Addressing possible implementations for each:

1. Client tells the server the user’s languages

Adding a query parameter to the URL with the user’s language code.

https://host.com/blink/action?locale=en,es,fr

Which languages are available on JavaScript thru:

navigator.languages
//["en-US", "en", "fr"]

//or fallback, if navigator.languages is not available in the users browser

navigator.language
//"en-US"

2. Server sends multiple JSONs

For this option, it could be done in multiple ways:

a) Passing an object on keys that can be localized, where the key of every entry is the language code and the value the localized text.

{
  ...
  "label" : { "es": "Coleccionar gratis", "en": "Collect for free" },
  ...
}

b) Having the entire JSON be in different keys, easier to maintain but it would not make sense for ** ActionPostResponse** that also have the transaction data, since you would have it repeated in both localized JSONs.

{
   "en":
   {
     ...
     "label" : "Collect for free",
     ...
   },
   "es":
   {
     ...
     "label" : "Coleccionar gratis",
     ...
   },
}

c) Having some sort of dictionary tags and a dictionary that has all the meanings of the tags, could be too much but adding it to the discussion.

{
  ...
  "label" : "collect_for_free",
  ...
}

Dictionary would look something like this:

{
  "en" : {"collect_for_free":"Collect for free"}
  "es" : {"collect_for_free":"Coleccionar gratis"}
}

What are your thoughts? Solana is very global, we don’t want to have Blinks be in english-only all the time, do we? :face_with_monocle:

Edit:

I think it should also apply to images, since in most cases we place text on images too. So letting define an URL or different URLs for images would be part of localizing it.

3 Likes
2

Text Localization would be a great optional addition for developers to add to their GET and POST responses.

Browsers and mobile devices already do a decent job of providing the current session’s language preferences on request, and individual extensions by wallets and other integrators could allow a user to set a default language preference for blinks that would override the browser/mobile preference if it exists.

Handling the default as English unless provided gives full backwards compatibility with the current solution, and providing the text in all languages (that dev has setup for this blink) handles scenarios where the user may want to toggle between languages on the UI without a full data refetch from server.

Making this a queryable parameter forces the spec to start reserving keywords or parts of the path, complications that would be good to avoid in the implementation spec. Instead I would advocate for returning all language definitions as defined by the developer, as an additional object in the fetchResponse or postResponse for each language localization. This would give frontends more control over how they choose which version to render by default and allow for smooth language handling in scenarios where preferred language isn’t defined by the developer.

It would be ideal to lean towards best practices created by communities such as the one around i18n or other internationalization frameworks, as they have already worked through the issues we would encounter. Examples of solved problems include text-within-images, variable text length in other languages causing wrapping issues, and extended character libraries causing broken text rendering if fallbacks aren’t supported. Ideally this upgrade is championed by someone who has already implemented localization at scale.

1 Like
3

this is a great idea in general: enabling localization.

I do think a simple approach could be used with headers.

  • blink clients could set and send the AcceptLanguage header with the locale of the user
  • the action api can read/parse this header value and provide the appropriate localized strings
  • if they dont care about localization, they can still just return action metadata as they do now

this would also simplify implementation and upkeep on part of blink clients since blink clients simply display the strings as they are returned. it becomes up to the action api to return the desired localized strings or image urls

related: we could also support color modes of users too (light mode or dark mode) in a similar way using headers sent from the client

1 Like