Skip to main content

Rigi Documentation

Will Rigi support my web application?

In theory, Rigi supports any web technology, including web applications, CMS, PIM, etc. However, the following basic requirements must be met.

Basic requirements

  • Texts should be externalized in resource files. All text appearing on the user interface must be externalized in resource files. Rigi supports many file formats and can develop custom parsers.

  • (Staging) The server should allow Multilingual support. It should be possible to select the Rigi language that allows Rigi to recognize user interface texts.

  • Browsers should use the Chromium engine , which is used by Chrome and Edge. You need the Chrome extension for Rigi (Rigi injector) to capture previews.

Web app requirements

  • Elements should contain one text (avoid row texts). Technically, an HTML element could contain multiple sub-elements, including text elements, such as: 

    <div>Hello<span>World</span></div>.

    To let Rigi recognize Rigi string, each string should have its own surrounding element, such as:

     <div><div>Hello</div><span>World</span></div>.

    Row texts

    An HTML element may contain multiple sub-elements, including text elements with Rigi tokens.

    <div>
         Hello  
         <span>world</span>
    </div>

    In live mode, the Rigi script will replace the text of the entire div-element with the translation of "Hello". This phenomenon is called "row text". The captured Rigi HTML previews will enclose translatable texts with rigi-el elements. The example above will become the following in a captured HTML preview:

    <div>
         <rigi-el>Hello</rigi-el> 
         <span><rigi-el>world</rigi-el></span>
    </div>

    This way, Rigi can replace all translatable texts in this Rigi HTML preview.

    Row texts and attributes

    Texts inside attributes should not be enclosed in rigi-el elements. Unfortunately, due to technical restrictions, RigiJS adds a rigi-el tag if a translatable text is surrounded by other texts. Fortunately, this situation does not occur frequently. The following table, where __x__ is a translatable text, shows the four possible cases.

    Input

    Result

    <span attrib="__x__"></span>

    <span attrib="__x__"></span>

    <span attrib="ABC__x__"></span>

    <span attrib="ABC__x__"></span>

    <span attrib="__x__DEF"></span>

    <span attrib="__x__DEF"></span>

    <span attrib= "ABC__x__DEF"></span>

    <span attrib= "ABC<rigi-el>__x__</rigi-el>DEF"></span>

    Another case is when START or END are also translatable text:

    Input

    Result

    <span attrib= "__x1____x2__"> </span>

    <span attrib= "<rigi-el>__x1__</rigi-el> <rigi-el>__x2__</rigi-el>"> </span>

  • Self-host resources. Rigi captures HTML previews that embed all images, fonts, CSS, etc. If your web application cross-references resources (for example, to another domain), then CORS restrictions forbid Rigi from capturing those resources.

    In those cases, Rigi will keep the existing URL. This works fine if the resources are publicly available (such as Google fonts). However, if users outside the firewall cannot access those resources, their Rigi previews can become messed up.

    Static links

    If you still need to refer to external resources, use static links.

    Example 28.

    The HTML links to a static resource:

    1.png

    The CSS imports the resource:

    2.png


  • Use shadow DOM as-is (if applicable). Rigi supports Shadow DOM. Developers should use a client framework as-is and not try to manually manipulate the shadow DOM. It can affect Rigi's ability to capture HTML previews.

  • Computed styles (JS). Rigi does not capture JavaScript (JS) code. Rigi captures HTML previews and embeds the computed styles. Ensure that the computed styles are defined when the page is captured.