Language Settings

Changing default language for GUI

The GUI ships in English and Polish. The i18n.locale setting in /etc/logserver-gui/logserver-gui.yml selects the language for the whole GUI instance, so every user who logs in through that node sees the same language. Users cannot pick a language for their own account.

Switching the GUI to Polish

  1. On every node that runs the GUI, edit /etc/logserver-gui/logserver-gui.yml and set:

    i18n.locale: "pl-PL"
    

    The file ships with this line commented out as #i18n.locale: "en-EN".

  2. Restart the GUI:

    systemctl restart logserver-gui
    
  3. Reload the page in the browser. The home page now shows the Polish texts:

To return to English, comment the i18n.locale line out again and restart logserver-gui.

The Polish translation covers the menus, the home page, Discover, Alerts and Config. A few elements stay in English:

  • the login page,

  • some values in drop-down lists, such as the rule types and alert methods in Alerts,

  • the time picker labels, such as Last 24 hours, and the date format.

Adding a translation for another language

  1. Prepare the translation file as described in Preparing translation for GUI and copy it to /usr/share/logserver-gui/translations/, for example as ja-JP.json.

  2. Add the file name to the translations list in /usr/share/logserver-gui/translations/.i18nrc.json:

    {
      "paths": {},
      "exclude": [],
      "translations": [
        "pl-PL.json",
        "ja-JP.json"
      ]
    }
    

    The GUI reads .i18nrc.json only from this directory. The package installs it as a configuration file, so an upgrade keeps your edited copy and saves a changed package version next to it as .i18nrc.json.rpmnew.

  3. Set the owner of the new file:

    chown logserver-gui:logserver-gui /usr/share/logserver-gui/translations/ja-JP.json
    
  4. Set the locale in /etc/logserver-gui/logserver-gui.yml:

    i18n.locale: "ja-JP"
    
  5. Restart the GUI with systemctl restart logserver-gui.

Preparing translation for GUI

Source file to use as a base for translations: /usr/share/logserver-gui/translations/en-EN.example.json

Bullet points for translations

For the translation to work you have to follow these steps.
Omitting some may result in missing translation in some parts of an application or an empty screen when entering a broken portion of an app.

The file with translation is JSON.

Translated values have the following structure:

{
    "message": {
      "key.for.the.value": "Translated value for the key"
    }
}

Every key is meant to be unique. There can be only one value for each key. In the messages object, each key has a “text” value, not a number and not an object.

But there are some structures in a source file that you will use as a base of your translation that have to be addressed during the process to achieve that.

  1. Objects

    {
      "messages": {
        "common.ui.aggTypes.buckets.filtersTitle": {
          "text": "Filters",
          "comment": "The name of an aggregation, that allows to specify multiple individual filters to group data by."
        }
      }
    }
    

    This has to be transformed as described above - a key common.ui.aggTypes.buckets.filtersTitle has to have a text assigned to it. The value that needs to be translated is in the fields “text” and “comment” described to you how the value needs to be translated. The result of such will be:

    {
      "messages":{
        "common.ui.aggTypes.buckets.filtersTitle": "Filtry"
      }
    }
    
  2. Template variables

    {
      "messages": {
        "common.ui.aggTypes.buckets.dateHistogramLabel": "{filedName} per {intervalDescription}"
      }
    }
    

    Any text that is encapsulated in {} has to be left as is. Those values are substituted by the application.

  3. How to treat complicated structures, eg.: plurals, etc.

    {
     "messages": {
       "kbn.discover.hitsPluralTitle": "{hits, plural, one {hit} other {hits}}"
     }
    }
    

    As of now, there is a single example of the above. Contrary to the last point the value in {} has to be translated for that key. So {hit} and {hits}.

  4. React compliant filenames

    In the application codebase, some methods will take translated keys and substitute them. But many of those will work only if the name of the translation file is one of:

    • en

    • en-US

    • en-xa

    • es

    • es-LA

    • fr

    • fr-FR

    • de

    • de-DE

    • ja

    • ja-JP

    • ko

    • ko-KR

    • zh

    • zh-CN

    • pl

    • ru

    • ru-BY

    • ru-KG

    • ru-KZ

    • ru-MD

    • ru-UA

FAQ

  1. Can I just paste everything into a basic(or advanced) translation software?
    ~No. There are some points to follow for the translation file to work at all.

  2. I have the following error - is the application broken:

    • Error formatting message: A message must be provided as a String or AST
      ~It is possible you have not followed point 1 - you have left some object structures in your file.

    • Blank page in GUI
      ~It is usually caused by not following point 2 -some variable names were changed.

  3. I have set “i18n.locale” in the configuration file but the app is not translated.
    ~You may have forgotten to put a reference for your file in .i18nrc.json file.

Known issues

  1. Some text may not be translated in Management -> Advanced settings even though keys for them are present in translation files.

  2. The same thing may happen in Discover -> View surrounding documents.


Settings

General Settings

The Settings tab is used to set the audit on different activities or events and consists of several fields:

  • Time Out in minutes field - this field defines the time after how many minutes the application will automatically log you off

  • Delete Application Tokens (in days) - in this field, we specify after what time the data from the audit should be deleted

  • Delete Audit Data (in days) field - in this field, we specify after what time the data from the audit should be deleted

  • The next fields are checkboxes in which we specify what kind of events are to be logged (saved) in the audit index. The events that can be monitored are: logging (Login), logging out (Logout), creating a user (Create User), deleting a user (Delete User), updating user (Update User), creating a role (Create Role), deleting a role (Delete Role), update of the role (Update Role), start of export (Export Start), delete of export (Export Delete), queries (Queries), result of the query (Content), if attempt was made to perform a series of operation (Bulk)

  • Delete Exported CSVs (in days) field - in this field, we specify after which time exported files with CSV extension have to be removed

  • Delete Exported PDFs (in days) field - in this field, we specify after which time exported files with PDF extension have to be removed

Each field is assigned the “Submit” button thanks to which we can confirm the changes.

License (License Info)

The License Information tab consists of several non-editable information fields.

Also, if you are logged in as an administrator you will be able to upload new license from here.

These fields contain information:

  • Company - who owns the license, in this case, Foo Bar.

  • Issued on - license creation date

  • Expiration date - when the license will expire

  • Days left - how many days left before it will expire

  • Data nodes in cluster - how many nodes we can put in one cluster - in this case, 10

  • SIEM Plan enabled - is SIEM Plan covered by the license

  • Network Probes - count of NetworkProbes covered by the license

  • No of documents - license can be limited by docs count

  • Indices - license can be limited by index pattern names

  • Version - version of the product

Renew license

To change the Energy Logserver license files on a running system, use the “Upload new license” option at the top of the “License” tab.

  1. Select the provided license files, e.g.: es_123.info, es_123.license.

  2. Click upload.

  3. Files will be uploaded and verified. New license information will appear.

  4. Verify new license information and click “Submit” when ready.

  5. It will install itself in the cluster - no need to manually put it on all nodes.

Special accounts

Apart from the administrative account, the installation creates a service account for each component that talks to the database. They are marked with the Internal flag in the User List and cannot be deleted. Find them under Management → Config → User Management → User List, filtering by account name.

  • logserver - used by the GUI, Cluster Console, Skimmer, and the Network Probe output

  • alert - used by the Alert engine, which evaluates rules against the incoming data and fires the configured notification method, see Alerting System

  • intelligence - used by the Empowered AI services, both intelligence and intelligence-scheduler, see AI and Analytics

  • e-doc - used by the wiki portal for its SSO callbacks and search index

  • license - used by the license service

  • probe - used by the Network Probe

The passwords of these accounts live in a central keystore and are rotated with logserver-password-util.sh, described in Change Default Credentials.