RFC: Radio localization in guest databases

The folks at eVectors want to be able to create Italian localizations of Radio, which they can update whenever they need to. Currently there’s no easy way to do this without providing access to our root updates server. 

However, if localizations could be stored in a subscribable guest database, then a Frontier server at eVectors server could handle the updates to the Italian localization, while UserLand’s root updates server continues to serve as the canonical Radio root updates server. 

This RFC details what’s needed to make localization work via a guest database. Proposed changes include a new preference for setting the language in Radio. They also address the possibility of using the same strategy for Manila and mainResponder localizations. 

Changes to frontier.getString 

frontier.getString is the verb that finds a localized string inside a language table.

A small change to this verb to make it follow addresses when searching for a string would make it easy for a language table to be stored in a guest database.

This makes it possible to decouple updates to a given localization, from UserLand’s root updates server.

Localization guest databases 

Localization databases are Tools, which have a localization table at the top-level of their database.

A localization table may contain any of the following application sub-tables: radio, manila, or mainResponder. These sub-tables correspond to the application being localized.

Each application sub-table contains one or more language sub-tables, whose name is the name of the language.

Here’s a sample table structure for an Italian localization database for Radio:

New prefs page 

In the Basic Preferences section — the first section of the prefs system, a new page: Language.

The page has some explanatory text, and a single pref — a pop-up menu: Language.

Items in this pop-up menu are determined by the sub-items of radio.data.localization.languages. For each sub-item i this table, there’s a corresponding option in the pop-up menu.

When submitted, user.prefs.language is set according to the chosen language.

Changes to Tools framework 

When a Tool is installed, the installer (frontier.tools.install) will check to see if the Tool’s database contains a localization table.

If so, it checks to see if the localization table contains a radio, manila or mainResponder sub-table.

For each of these application tables, the address of all language sub-tables is installed in the built-in localization table for the given application.

For example, the Italian Tool above would install an address at radio.data.localization.languages.italian, whose value is @[“italian.root”].italianLocalization.radio.italian.

This way, frontier.getString will be able to find strings in the localization database, when user.prefs.language is “Italian”.

New verb: frontier.getLocalizedObject 

While there’s a built-in verb for finding a localized string, there’s no equivalent built-in verb for finding, for example, a help or prefs outline.

Behavior of frontier.getLocalizedString is uses the same logic as frontier.getString. Instead of returning the localized object, it returns the object’s address.

frontier.getLocalizedObject (id, adrLanguageTable, defaultLanguage=nil)

id — the dot-delimited ID of the object, for example, “outlines.prefs”

adrLanguageTable — the address of the localized language table in which to search for the object, for example @radio.data.localization.languages.english.

defaultLanguage — the default language. If not specified, the value at user.prefs.languge is used. If user.prefs.language is not defined, “english” is assumed.

Change to radio.prefs.browseSystemPrefs 

This script has hard-coded, the address of the prefs outline. The change would be to call frontier.getLocalizedObject, to get the address of the prefs outline instead.

Change to radio.prefs.browseHelp 

Like radio.prefs.browseSystemPrefs, this script has hard-coded the address of the help outline. It should also call frontier.getLocalizedObject.