:::
This is not a request but rather a proposal.
Recently, I rewrote Translator for my purpose, but if someone has interests, I’ll make a PR to the original repository to share.
Anyway, I need some help; test, proof of concept.

I’m just afraid that I was the only one who needs this.

I apologise in advance for a too-long article to read.
:::

MagicMirror² Enhanced Translator

This project is rewriting the global Translator object of MagicMirror to have enhanced features.

• dev repository : https://github.com/MMRIZE/MagicMirror_EnhancedTranslator
• dev branch : https://github.com/MMRIZE/MagicMirror_EnhancedTranslator/tree/enhanced-translator (original based 2.16-develop of MicMich/MagicMirror)
• demo branch(here) : https://github.com/MMRIZE/MagicMirror_EnhancedTranslator/tree/master

Motivation

For several years, the current translator class works for L10N/I18N of MM successfully. But there is still some lack of features. Especially in the below cases, we need more improvements.

• Maintenance of translation files.

  Whenever a new translation by the user is added or updated, translations.js(core) or .getTranslations()(module) should be updated and released officially to prevent the update-conflicts issue.

  By versioning up, some old translation might be obsoleted or needs to be updated for the change of terms used in MM.

  And also, it is hard to add a light-modified custom dictionary like de-au.json. It would probably be copied from the original de.json, and even though the difference might be very little, but entire de-au.json should be published and maintained.

• Locale-aware

  One xx.json cannot hold several locale-specific translations difference. US English and Australian English are noticeably different from each other from vocabulary to grammar. Some Australian users may prefer "G’day mate" instead of "Hello". Some British people might not be comfortable with the spelling of "Color".

  English users in Canada(en-CA) notate dates as 4 September 2021 or September 4, 2021, And French in Canada(fr-CA) notate date as 4 septembre 2021. and the usual numeric format is 2021-09-04. But in the US(en-US), people genrally use 09/04/2021. And in France(fr-FR) it is 04/09/21.

  German people prefer to write a number like 1.234.567,89, but in US, it will be 1,234,567.89. In India, it will be 12,34,567.89. In China, under ‘hanidec’ numbering format, it will be 一,二三四,五六七.八九.

  Generally, MM module developers have tried to solve these issues by providing specific additional L10N converting by config. But occasionally it makes another too-many-config-value issue.

  And for the date format, we are facing momentJS deprecation. (Well, luxon might be the excellent alternative, though.)

• For multi-lingual user (too-simple-fallback)

  Current fallback mechanism - primary language or ‘en’ is not enough. Some people use multi-languages in their country.

  Certain Serbian users can speak Serbian, Croatian, Romanian, Hungarian, Slovak, Czech, etc. Anyway English might not be his prefer language. With luck, some modules might provide hu.json. and some modules might provide hr.json. But he should select only one language for his Mirror. And whatever he chooses, other modules will display English. Of course, en must be the last-final-safe fallback. However, it will be convenient and user-friendly if MM provided more steps before the final solution.

  Also, there could be cases like this; sometimes fr-CA user needs fr-CA translation at first, then want to use familiar fr, then en-CA if available, at last reluctantly use standard en as final fallback.

• flexibility for natural language process

  translator is not a template engine. However, if it could handle Object and Array it would provide more abundant natural translation results. In some counties, the first name is preferred to Family name, and in some countries, vice versa. If translator can handle user: {firstName, familyName, gender, title} together instead of addressing each userFirstName, userFamilyName, userGender, userTitle, it could reduce the codes and make meaningful context.

  Customizable value-formatters would be a help for L10N/I18N also. A Module developer needs to support only general value and format, and then a translation provider could convert that value to another format with those formatter on dictionaries.

  For example; Instead of "Unread mail: 3", more natural sentences "There is a mail unread.", "There are 3 mails unread." or "Es gibt eine ungelesene Mail.", "Es sind 3 Mails ungelesen" could be possible with some formatters and language/locale information by translation provider, not by module developer himself.

  Finally, translation could be used as a light template engine with those features. It will give more freedom to the user who wants to customize the MM.

Those are the main reason what this project begins.

Improvements

• Multi-language fallback by prefer order and related-locales
• Translation dictionaries autoload
• Handling Object and Array as replacement variables
• custom value formatting

Usage

config and fallback order

// in `config.js`
language: "fr-CH",
languages: ["it", "de-CH"],
locale: "fr-CH",

• config.languages are proposed. You can define multi-languages to use by preferred order.

• For backward compatibility, config.language would still be used. config.language will be regarded as a primary language. In above example, this configuration is same with languages: ["fr-CH", "it", "de-CH"]. (translator itself doesn’t refer config.language but other modules might be using it.)

• For convenience, config.languages: "it, de-CH" would also be allowed.

• "en-CA" or "en-ca" would be suitable for language code. But don’t use "en_CA". Ithe t is not standard BCP-47 format.

• Each locale-like language code implies to refer its ancestor dictionaries. "fr-CH" will use fr-ch.json and fr.json. When translator cannot find the term in the fr-ch.json, it will try to seek from fr.json. Another case; zh-Hans-HK will try zh-hans-hk.json then zh-hans.json, then zh.json (and finally en.json, of course). But zh-hant.json or zh-tw.json will not be referred.

• So, in the above case, the translator will refer to dictionaries by order - fr-ch, fr, it, de-ch, de and the final implied fallback en.

• If the translator cannot find any term or dictionary in module’s /translations, it will try MM’s /translations(core). If nothing is matched in the end, null or runtime fallback message(from .translate()) would be returned.

• So you can extend your sub-dictionary easily. If you already have a complete dictionary - de.json, you can make de-au.json without copying whole terms. Just describe exclusive terms only being different with de.json. All other unmentioned terms in de-au.json will be referred from de.json automatically.

• locale would be needed. If not described, default would be used in translator, and it would generally infer your default system locale.

translation file and syntax

• For backward compatibility; same naming rule with current lower capitalized BCP-47 format. (e.g. en.json, en-ca.json)

  By the way, current MM’s translations files are not fully fitted for BCP-47. kr.json should be ko.json, etc…

• For developer; You don’t need to maintain translations.js or .getTranslations(). Needed translation files that exist in /translations directory will be loaded automatically by the user’s configuration.

• For backward compatibility; same syntax with current - "TERMS" : "DEFINITION" is still used. (e.g. { "SAY_HELLO" : "Hello, {userName}!" })

• (new) Nested Object/Array index is usable. (e.g. { "SAY_HELLO" : "Hello, {user.0.name} and {user.1.name}!" })

• (new) pre-defined or custom formatter is usable. Formatter symbol is @. (e.g. { "TIME_INSTANT" : "It's {now@myTime}" }). Variable now will be converted to specific format by definition of @myTime formatter defined in translation dictionary.

• (new) Definition of formatter could be added. Translation file provider can adjust options to format the variable replacements for his language/locale.

• Drawback; Dynamic loading translation files on runtime could spit out dev-console 404 error messages, because translator doesn’t know that every translations exist or not. Error messages make no harm and they are ignorable, but annoying anyway.

Example

// in MM-Something module
var translated = this.translate("TIME_INSTANT", { now: new Date() });
// => It's Monday, 9 in the morning.

/* modules/MM-Something/translations/en.json */
{
  "SAY_HELLO": "Hello, {user.name}!",
  "TIME_INSTANT": "It's {now@myTime}.",

  "@myTime": {
    "format": "DateTimeFormat",
    "options": { "dayPeriod": "short", "hour12": true, "weekday": "long", "hour": "numeric" }
  }
}

/* modules/MM-Something/translations/de.json */
{
  "SAY_HELLO": "Hallo, {user.name}!",
  "TIME_INSTANT": "Es ist {now@myTime}.",

  "@myTime": {
    "format": "DateTimeFormat",
    "options": { "dateStyle": "long", "timeStyle": "short" }
  }
}

With locale = "en-US" and language = "en", translated result will be It's Monday, 9 at night.

With locale = "de-DE" and language = "de", translated result will be Es ist 6. September 2021 um 21:09.

As it shows, module developer doesn’t need to preserve every available conversion result. Translator maker could format it by himself for his locale and language.

Translator spec.

(module).translate(key [, variablesObject][, fallbackMessage][, asObject])

• key {string} (required) terms identifier to translate.
• variableObject {object} (optional) replacement values as object.
• fallbackMessage {string} (optional) fallback message.
• asObject {boolean} (optional) return translated result as object instead string. When you need more info about translated result, set this to true.

Each optional values are omittable.

this.translate("SAY_HELLO");
this.translate("SAY_HELLO", true);
this.translate("SAY_HELLO", { name: "Tom" });
this.translate("SAY_HELLO", { name: "Tom" }, true);
this.translate("SAY_HELLO", "Hello, nobody");
this.translate("SAY_HELLO", "Hello, nobody", true);
this.translate("SAY_HELLO", { name: "Tom" }, "Hello, nobody");
this.translate("SAY_HELLO", { name: "Tom" }, "Hello, nobody", true);

Return value will become a translated result with the variables. When translations would be failed(not found terms in all the dictionaries, some error causing, invalid variables, etc.)

When asObject set as true, the return object would have these properties;

{
  key, // original seeking term
    variables, // replacement
    asObject, // return value as object or string
    language, // which language is used
    source, // translation template before replacement with variables
    translated, // final translated result
    criteria, // where the dictionary locates ('core' or each module)
    fallback, // fallback message from `.translate()`
    moduleName, // which module call this
    toString(); // toString method. return value will be same with `translated`
}

In general module developing, this.translate() might be waht all you need to know. But for more control of translator, you can use the below methods.

Translator.getLanguages()

It will return current array of language list used in Translator by seeking order. Usually it will be a combination mix of config.language and config.languages.

Translator.getLocale()

It will return current locale value. Usually it will be a BCP-47 regulated config.locale. When the user’s locale info is not proper, it will have default as a default value.

Translator.registerFormatter(formatName, formatFunc)

• formatName {string} (required) format identifier
• formatFunc {Function} (required) callback function to format value.
  • formatFunc will get a format object as a parameter when it called.
  • Format object will have this property.

{
  value,  // original value from replacement variables to format by this formatter
  locale, // If not described in dictionary, default locale value of translator will be used
  ...rest // all other values of user definition in dictionary
}

With this method, you can add or overwrite global formatter from your module.

Example

// in MM-Something module.
Translator.registerFormatter("TemperatureConverter", function ({ value, locale, options } = {}) {
  if (isNaN(value)) return value;
  if (locale === "en-US") {
    // // just for example of how to use locale.
    options.unit = "°F";
    options.convert = "c2f";
  }
  var unit = options.unit ? options.unit : "";
  if (options.convert) {
    if (options.convert.toLowerCase() === "c2f") return Math.round((value * 9 * 10) / 5) / 10 + 32 + unit;
    if (options.convert.toLowerCase() === "f2c") return Math.round(((value - 32) / 9) * 5 * 10) / 10 + unit;
  }
  return value + unit;
});

// ...

var translated = this.translate("CURRENT_TEMP", { temp: 22 });
// It will have 'It is 71.6°F.' as defined in dictionary.

/* in translation file */
{
  "CURRENT_TEMP": "It is {temp@myTemp}.",

  "@myTemp": {
    "format": "TemperatureConverter",
    "options": { "unit": "°F", "convert": "c2f" }
    /* "locale": "en-US" */
  }
}

Regardless of whatever original locale is, translation provider can set locale to be used frocely for fromatting in this translation when he sets locale.

Ready-made formats.

NumberFormat

Implementation of Intl.NumberFormat - more info

You can change the number values to various formats for the locale - currency, unit, conversion, separtor grouping, aproximation, etc. See above link.

• input variable type : number or calculable data (e.g. stringified number - “123”)
• using properties in translation : options, locale

Examples of what possible

• 123456.789 => “123.456,79 €”
• 123456.789 => “￥ 123,457”
• 123456.789 => “1,23,000”
• 3500 => “3,500 liters”
• -3500 => “-$3,500.00”
• 987654321 => “988M”

DateTimeFormat

Implementation of Intl.DateTimeFormat - more info

You can change the date values to various formats for the locale - various calendar/date/time/timezone and misc. parts.

• input variable type : Date object or date-like data (e.g. stringified date - “2021-08-19 12:34:56”)
• using properties in translation : options, locale

Examples of what possible

• 2021-01-23 01:23:45 => “23/01/2021” or “21/01/23 Mon.” or “1 at night”, etc. by locale and format option

RelativeTimeFormat

Implementation of Intl.RelativeTimeFormat - more info

You can convert period to relative humanized format by unit.

• input variable type : number or calculable data (e.g. stringified number - “123”) as period
• using properties in translation : options, locale, unit

Examples of what possible

• “2 hours ago”, “tomorrow”, “in 3 days”

RelativeTimeFormat needs base unit to calculate. AutoScaledRelativeTimeFormat will auto calculate unit for convenience. See below.

AutoScaledRelativeTimeFormat

Similar to RelativeTimeFormat but unit will be decided automatically. The period is calculated based on the current time.

• input variable type : Date object or date-like data (e.g. stringified date - “2021-08-19 12:34:56”)
• using properties in translation : options, locale

ListFormat

Implementation of Intl.ListFormat - more info

You can list items with language-sensitive list formatting.

• input variable type : array of string
• using properties in translation : options, locale

Examples of what possible

• [‘A’, ‘B’, ‘C’] => “A, B, and C”
• [‘A’, ‘B’, ‘C’] => “A, B und C”
• [‘A’, ‘B’, ‘C’] => “A, B oder C”
• [‘A’, ‘B’, ‘C’] => “A, B, C”
• [‘A’, ‘B’, ‘C’] => “A B C”

PluralRules

Implementation of Intl.PluralRules - more info

It enables plural-sensitive formatting and plural-related language rules.

• input variable type : number or calculable data (e.g. stringified number - “123”)
• using properties in translation : options, locale, rules

Examples of what possible

• “I have 1 ball.” / “I have 3 balls.”
• “1st, 2nd, 3rd, 4th, 11th, 12th, 13th, 21st, 22nd, 23rd”

/* in translation xx.json */
{
  "I_HAVE_BALL": "I have {count} ball{count@plural_postfix_s}.",
  "@plural_postfix_s": {
    "format": "PluralRules",
    "options": { "type": "ordinal" },
    "rules": {
      "one": "",
      "other": "s"
    }
  }
}

Select

Simple conditional value converter

• input variable type : string
• using properties in translation : rules

/* in translation xx.json */
{
  "STATUS": "Main job is {status@mySelect}.",
  "@mySelect": {
    "rules": {
      "ONGOING": "processing now",
      "STOP": "stopped",
      "FINISH": "completed",
      "other": "working"
    }
  }
}

When this formatter cannot find the matched rule with given value, "other" will be used.

this.translate("STATUS", { status: "ONGOING" });
// => 'Main job is processing now.'
this.translate("STATUS", { status: "PREPARED" });
// => 'Main job is working.'

Current dev status

• based on MM 2.16 dev (2.17 beta).

• All spec. described above is implemented.

• new Unit Test for translator is written and is passed.

  unit test : jest tests/unit/classes/translator_spec.js -i --forceExit

I haven’t made PR to main MM repository, because;

• (TODO) e2e test. > but I have no idea how to build it. I need a help.

• (TODO) Documentation > new trnaslator probably need a documentation for the users. I need a help too, because I’m not a native English user so my skill of writing is not enough.

• (TODO maybe) Sharing translator for node_helper

To this moment, I’m not sure whether this project has worthy to be included in main MM project or not. Will this be useful? I’m afraid that I’m the only one who needs these enhanced feature.

Thanks.

Seongnoh Yi (eouia0819@gmail.com)

@0m4r
I was the original author of that module.
Basically, if any module could emit any notification and it could be translated properly, it will work.
You can define your customization with payloadConverter and notification in config.js

notification: "SOME MODULE NOTI",
payloadConverter:(payload)=>{
        return  "windy night spring"  // <= query text for the image.  
}

Currently, this module is managed by brianHelper

Though I’m not using Windows anymore, I always envy the Rainmeter despite its ridiculous instability and low performance.
10 minutes ago, suddenly I remembered the idea that the Electron could be used for that purpose. That means I can use MM as a desktop wallpaper. So I did.

Here’s how to do it.

For disclaimers, Electron cannot hook Windows Desktop by itself. There are a few solutions for that, but I don’t want to hack MM heavily. For Windows, use Rainmeter.

custom.css

:root {
  --color-text: #DDD;
  --color-text-dimmed: #BBB;
  --color-text-bright: #fff;
  --color-background: rgba(0, 0, 0, 0);
 /* make fonts color brighter */

  --font-size: 2vh;
  --font-size-small: 0.75rem;

  --gap-body-top: 20px;
  --gap-body-right: 120px;
  --gap-body-bottom: 20px;
  --gap-body-left: 40px;
/* adjust margin for your screen */
}

* {
  text-shadow: 2px 2px 5px #000000; /* make text more readable on the background image */
}

config.js

In the case of Linux, some options might need to be modified.

electronOptions: {
  /*
  x: 1920,
  y: -320,
  width: 3360,
  height: 1892,
  */
  width: 1920,
  height: 1200,
  fullscreen:  false,
  backgroundColor: '#00000000',
  titleBarStyle: 'none',
  frame: false,
  type: 'desktop',
  hasShadow: false,
  transparent: true,
  resizable:   false,
},

• width, height : Your screen resolution
• x, y : position offset from 0, 0 for the left-upper corner of MM screen.

If you are using multi-screen like this and you want to place MM to secondary monitor;

You can adjust x and y to move MM to the secondary monitor.

js/electron.js

I’m not sure this is necessary. but when above modification is not enough, try this.

// line 22 of electron.js
// Change this line
app.commandLine.appendSwitch("autoplay-policy", "no-user-gesture-required");

// to this.
app.commandLine.appendSwitch("autoplay-policy", "no-user-gesture-required", "enable-transparent-visuals");

This needs source modification. I already made a PR to enable customizing electron switches, but this online source modification is needed before acceptance of that PR.

I tested it on macOS, and I believe it will be working on Linux also. Have good luck.

@nyghtx
I used the same hw with you,(in my case, controller is slightly different anyway)
Most possible reason might be the physical connection is broken. Keep the cable plugging tightly.

@pillaresci
Exactly what do you want to do? Let’s break one by one.

My desktop clock? calendar? whatever…

• RPI 4B
• 1920x480 Touch LCD /w case unit from AliExpress.

with some modules modification and scripts, it could become a 9to5 office gadget.

I need some more angled plugs for a better look, anyway 90% done.

@harmzj

I believe this is similar to what you want.

{
  module: "MMM-CalendarExt2",
  config: {
    calendars: [
      {
        name: "Tottenham",
        url: "https://www.google.com/calendar/ical/ovb564thnod82u5c4njut98728%40group.calendar.google.com/public/basic.ics",
        icon: "emojione:chicken"
      },
      {
        name: "Leeds",
        url: "https://www.google.com/calendar/ical/h2suh4c1iqvktk4olmfqtth4lg%40group.calendar.google.com/public/basic.ics",
        icon: "emojione-v1:shield"
      }
    ],
    views: [
      {
        name: "UPCOMING_GAME",
        calendars: ["Tottenham", "Leeds"],
        mode: "upcoming",
        slotMaxHeight: "150px",
        position: "top_left",
        positionOrder: 1
      },
      {
        name: "DAILY_GAME",
        calendars: ["Tottenham", "Leeds"],
        mode: "daily",
        type: "row",
        positionOrder: 0,
        slotCount: 5,
        slotMaxHeight: "100px",
        slotSubTitleFormat: "MMM do",
        position: "bottom_bar"
      }
    ],
    scenes: [
      {
        name: "DEFAULT",
        views: ["UPCOMING_GAME", "DAILY_GAME"],
      }
    ]
  }
}

@harmzj
I am going on driving in a minute. So cannot reply detailly. If you don’t mind I’ll show you the example in 1-2 hours. Anyway, it will be better to show your current config.js MMM-CalendarExt2 parts here.

@nyghtx
I used the same hw with you,(in my case, controller is slightly different anyway)
Most possible reason might be the physical connection is broken. Keep the cable plugging tightly.

@harmzj NO!
Users SHOULD NOT modify source at any reason. You HAVE TO adjust your config file.
See the example; https://forum.magicmirror.builders/topic/15614/mmm-calendarext2-example-request/2

@harmzj
Current in top_left region

clock (0)
RSS (1)

What you want

clock (0)
Your CALEXTVIEW (1)
Rss (2)

Set position order to 1. It will place the view in the second position.
It is zero-based, so if you set 0, it means the first position(clock)

@cowboysdude
Yup, Every developer can implement his own logic to display time-related stuff. And hundreds of MM modules are there, so hundreds of implementations are existing also, just to display “in 15 days”.
I think it is a kind of waste. So I propose a reusable common HTML tag anyone can use anywhere.

But the most benefit of this custom tag is, in my thought, Customizability and Locale-awareness separated from the module itself. Logic-neutral HTML tag could give the ability of easier user-customization without the developer’s effort. That is the purpose of this custom tag.

@sdetweil right. Anyway we will not rewrite mm with angular or vue. (I prefer vue)

@reniwqwil5

{
  module: "MMM-CalendarExt2",
  config: {
    calendars: [
      {
        name: "Tottenham",
        url: "https://www.google.com/calendar/ical/ovb564thnod82u5c4njut98728%40group.calendar.google.com/public/basic.ics",
        icon: "emojione:chicken"
      },
      {
        name: "Leeds",
        url: "https://www.google.com/calendar/ical/h2suh4c1iqvktk4olmfqtth4lg%40group.calendar.google.com/public/basic.ics",
        icon: "emojione-v1:shield"
      }
    ],
    views: [
      {
        name: "UPCOMING_GAME",
        calendars: ["Tottenham", "Leeds"],
        mode: "upcoming",
        slotMaxHeight: "240px",
        position: "top_right",
      },
      {
        name: "MONTH",
        calendars: ["Tottenham", "Leeds"],
        mode: "month",
        slotMaxHeight: "75px",
        position: "bottom_bar"
      }
    ],
    scenes: [
      {
        name: "DEFAULT",
        views: ["UPCOMING_GAME", "MONTH"],
      }
    ]
  }
},

More config options and CSS customizing are needed to display pretty, but anyway, you can understand the basic concept.
Calendars -> Views -> Secnes.

I was the original author of this module, but I ran away from this module’s maintenance, sorry. (I had bad days personally at that period)
I always thought this module has too much over-spec to use simply.
Due to the dying of dependency - momentJS’, this module would be archived anyway in near future. I have no idea whether I make alternative or equivalent at this moment.

MMM-CustomElementTime

As always, the manual is longer than the codes. What’s wrong with my modules.

• Author: Seongnoh Sean Yi eouia0819@gmail.com
• Repository : https://github.com/MMRIZE/MMM-CustomElementTime
• Version: 1.0.0 (2021-09-24)

I. Motivation & Concept

Tons of MM modules have been handling time-related stuff for many years. A module developer needs to implement his logic to display “in 5 minutes” or “Friday, 25. December”. Yup. It looks pretty straightforward at first glance until considering customizability or localization features. There was a relatively easy solution like momentJS. But now we are facing of deprecation of momentJS. Maybe luxon would be the best alternative, but…

JavaScript environment is evolving every day so fast. Now we can obtain brand new(Frankly, they have existed for several years already) weapons - Custom Element and Intl. I think these new features will change (and is changing) the whole things of Javascript applications, including MagicMirror.

This MM module gives the custom element <mm-time>, which can display time in the MM screen anywhere.

This module is not just for average users, and even more, it is a THING for developers. However, even ordinary users can use this tag wherever they want, and HTML is allowed. For example, you can put this <mm-time> tag in the helloworld module to display your custom world-clocks or event countdown.

For the developer; you can use this tag to reduce your code and not worry about handling displaying time. With just inserting <mm-time> into your module’s screen output, you don’t need to make logic for taking time-related stuff by yourself. Additionally, this tag can give more than your expectation.

This module and custom tag <mm-time> is made with only pure Javascript. Without momentJS or something 3rd Party dependency, probably you can handle the time how to show, I hope. (But the calculation of time is a different perspective.)

Features summary

You can get <mm-time> custom element (a.k.a web components), which enables to display time with these features;

• self-redraw
• alarm
• locale/language-aware
• relative-humanized
• customizable
• programmable/controllable in other modules
• shoot-and-forget about time manipulating.
• without 3rd party library/dependency
• placable anywhere HTML is allowed

More Details;
https://github.com/MMRIZE/MMM-CustomElementTime

My desktop clock? calendar? whatever…

• RPI 4B
• 1920x480 Touch LCD /w case unit from AliExpress.

with some modules modification and scripts, it could become a 9to5 office gadget.

I need some more angled plugs for a better look, anyway 90% done.