RPC Calls for Extensions

[tinganho]

We use JSON RPC to communicate with an Extension Server. The communication uses a TCP/UNIX socket.

There are primarily two RPC methods, compile and sync, for compiling and syncing localization keys.

Compile

Compiles the localizations from storage to source code. L10ns will send over an abstract syntax tree over to the Extension Server. This is to prevent multiple sources of truths. For example, one can interpret one syntax differently in one extension compared to another extension. We also want to make it easier for developers to develop extensions and we think if they could skip developing parsers for creating AST:s it would cut the complexity of creating extensions by a lot.

The extension then uses the MessageFormat's Abstract Syntax Tree to compile the localization strings, by visiting each node in the AST.

Because, localization data is needed to compile the localization string, they are sent as part of the argument as well. They are sent as part of the argument because parsing and extracting data from CLDR and IANA is a pain.

• Parameters:
  • LocalizationStrings.

interface MessageFormat {
}

interface PluralFormData {
    zero: string;
    one: string;
    two: string;
    few: string;
    many: string;
    other: string;
}

interface LocalizationData {
    Type: 'PluralForm' | 'OrdinalForm' ...
    Data: PluralFormData | OrdinalFormData ...
}

interface Parameter {
    Name: string;
    Type: 'int32' | 'int64' | 'uint32' | 'uint64' | 'sint32' | 'sint64' | 'float' | 'double' | 'string' | '$SYMBOL_NAME'; // $SYMBOL_NAME is the name of a symbol
}

interface Localization {
    Key: string;
    Value: MessageFormat;
    Parameters: Parameter[];
    LocalizationData: LocalizationData;
}

interface LocalizationStrings {
    [language: string]: Localization[];
}

• Returns:
  • Success or Error according to JSON RPC 2.0 specs.

Sync

All files are sent over to the Extension Server as an array. L10ns generates a checksum for each file. This checksum is then checked on future synchronizations to prevent sending unnecessary files. Only the files that are changed is sent over to the Extension Server.

The Extension Server then reads all these files. And extracts all the localization keys of it and returns localization keys(along with their parameter identifiers) associated with each file. Note, it should return all localization keys regardless if some are deleted or added. L10ns keep track of showing which are deleted or added to the user. L10ns offsets this complexity from the extension developer.

• Params:
  • Files string[].
  • Functions

{
    "Files": [
        "/Path/To/File1",
        "/Path/To/File2",
        "/Path/To/File3",
        "/Path/To/File4"
    ],
    "Functions": ["this.l", "l"]
}

• Returns

{
    "/Path/To/File1": [
        {
            "Id": "FIRST_NAME_INPUT",
            "Parameters": [
                {
                    "Name": "Some",
                    "Type": "int32",
                }
            ]
        }
    ]
}