Press the green checkmark (or red cross if something went bad). Then look at the list of jobs and their status:
Then look for any of the entires that starts with “Main” and press the “Details” link next to it. It doesn't really matter which platform you'll choose as the artifacts are available on the same page.
better-sqlite3 requires a native module in order to work. In order to ease the installation process, prebuilt binaries are provided by the library developers.
Trilium Next started with version 8.4.0 for better-sqlite3
To import the library, simply use the following mechanism:
import library_loader from "./library_loader.js";
-await library_loader.requireLibrary(library_loader.I18NEXT);
Make sure to replace I18NEXT with the library that was created at the previous steps.
Note that because we are not using a module management mechanism such as ES Modules or Common.js modules, the requireLibrary method does not actually return anything.
To benefit from the library, it must export on its own an object in window.
In the case of i18next, it sets window.i18next and that can be used directly:
Make sure to replace I18NEXT with the library that was created at the previous steps.
Note that because we are not using a module management mechanism such as ES Modules or Common.js modules, the requireLibrary method does not actually return anything.
To benefit from the library, it must export on its own an object in window.
In the case of i18next, it sets window.i18next and that can be used directly:
i18next.init({});
Step 5. Adding Electron support
For Electron, the node_modules are copied as a separate step by bin/copy-dist.ts.
Scroll all the way down to the nodeModulesFolder and append an entry for the newly added libraries.
better-sqlite3 has native Node bindings. With updates of better-sqlite3, but also of Electron and Node.js versions, these bindings need to be updated.
Note that Electron and Node.js versions need different versions of these bindings, since Electron usually packs a different version of Node.js.
During development, npm install tries to build or reuse prebuilt natives for the current Node.js version. This makes npm run start-server work out of the box. Trying to run npm run start-electron with these versions generally causes an error such as this:
Uncaught Exception:
+Error: The module '/Users/elian/Projects/Notes/node_modules/better-sqlite3/build/Release/better_sqlite3.node'
+was compiled against a different Node.js version using
+NODE_MODULE_VERSION 108. This version of Node.js requires
+NODE_MODULE_VERSION 116. Please try re-compiling or re-installing
+the module (for instance, using `npm rebuild` or `npm install`).
How the natives are handled
Locally, this can be fixed by rebuilding the binaries, which is what npm run switch-electron does, which uses electron-rebuild under the hood.
When the deliveries are built (see Build deliveries locally), it is not feasible to rebuild the dependencies since we are building for multiple platforms. Luckily, better-sqlite3 provides these prebuilt binaries from us, available as artifacts on their GitHub releases page.
The build script manages the natives for better-sqlite3 by keeping a copy of the .node file for every platform in bin/better-sqlite3.
Whenever the version of better-sqlite3 changes, the .node files must also be renewed based on their releases page. To simplify this process, a script was created in bin/better-sqlite3/update.sh.
How to update the natives
The update script needs to know the version of Electron or Node.js for which to download the prebuilt binaries.
If you get errors during download, check on the releases page to ensure that this particular combination of Electron/Node actually exists for the given release.
To determine the NODE_MODULE_VERSION that is required, look for This version of Node.js requires NODE_MODULE_VERSION in the error when starting Trilium via:
npm run start-electron (or run any Electron delivery), case in which the ELECTRON_VERSION variable needs to be changed.
npm run start-server (or run the Linux server delivery), case in which the NODE_VERSION variable needs to be changed.
Check which files got changed after running the update script and for each platform that got changed, test it locally via Build deliveries locally or via the CI.
If running the server using npm run start-server, the server will watch for changes in src/public and trigger a frontend reload if that occurs.
Electron live reload
Similarly, npm run start-electron supports live refresh as well.
However, a core difference is that Electron watches dist/src/public instead of src/public since Electron runs on its own copy of the files.
To ameliorate that, a separate watch script has been implemented which automatically copies files from src/public to dist/src/public whenever a change is detected. To run it:
npm run
Technical details
This mechanism is managed at server level by watching for changes inservices/ws.ts.
Use hierarchy whenever appropriate, try to group the messages by:
Modals (e.g. about.foo, jump_to_note.foo)
Don't duplicate messages that are very widely used.
One such example is aria-label="Close" which should go to a single message such as modal.close instead of being duplicated in every modal.
On the other hand, don't overly generalise messages. A close message that is used whenever the “Close” word is encountered is not a good approach since it can potentially cause issues due to lack of context.
If you see multiple messages joined together only to apply add a variable such as a user-inputted value, try to join those messages together into a single message containing a variable.
So instead of “Number of updates: “ + numUpdates + “.” use $(t("number_updates", { numUpdates })) where the message translation would appear as Number of updates: {{numUpdates}}.
To add a new locale, go to src/public/translations with your favorite text editor and copy the en directory.
Rename the copy to the ISO code (e.g. fr, ro) of the language being translated.
Translations with a country-language combination, using their corresponding ISO code (e.g. fr_FR, fr_BE), has not been tested yet.
Changing the language
Since the internationalisation process is in its early stages, there is no user-facing way to switch the language.
To change the language manually, edit src/public/app/services/i18n.js and look for the line containing lng: "en". Replace en with the desired language code (from the ones available in src/public/translations).
Recommendations
Use hierarchy whenever appropriate, try to group the messages by:
Modals (e.g. about.foo, jump_to_note.foo)
Don't duplicate messages that are very widely used.
One such example is aria-label="Close" which should go to a single message such as modal.close instead of being duplicated in every modal.
On the other hand, don't overly generalise messages. A close message that is used whenever the “Close” word is encountered is not a good approach since it can potentially cause issues due to lack of context.
If you see multiple messages joined together only to apply add a variable such as a user-inputted value, try to join those messages together into a single message containing a variable.
So instead of “Number of updates: “ + numUpdates + “.” use $(t("number_updates", { numUpdates })) where the message translation would appear as Number of updates: {{numUpdates}}.
Client-side translations
Component-level translations
Most of the client translations are present in the various widgets and layouts.
Translation support has to be added manually for every file.
The first step is to add the translation import with a relative import. For example, if we are in the src/public/app/widgets/dialogs directory, the import would look as follows:
import { t } from "../../services/i18n.js";
Afterwards, simply replace the hard-coded message with:
${t("msgid")}
where msgid is the key of the message being translated.
Template-level translations
Templates are .ejs files present in src/views, these are used to prepare the root layout for desktop, mobile applications as well as setup (onboarding) and the shared notes view.
Due to using a different approach, it is not possible yet to translate those files.
Server-side translations
Currently the server-side messages are not translatable. They will be added as a separate step.
+}
Follow the Guidelines when creating a new message.
Adding a new locale
To add a new locale, go to src/public/translations with your favorite text editor and copy the en directory.
Rename the copy to the ISO code (e.g. fr, ro) of the language being translated.
Translations with a country-language combination, using their corresponding ISO code (e.g. fr_FR, fr_BE), has not been tested yet.
Changing the language
Since the internationalisation process is in its early stages, there is no user-facing way to switch the language.
To change the language manually, edit src/public/app/services/i18n.js and look for the line containing lng: "en". Replace en with the desired language code (from the ones available in src/public/translations).
Client-side translations
Component-level translations
Most of the client translations are present in the various widgets and layouts.
Translation support has to be added manually for every file.
The first step is to add the translation import with a relative import. For example, if we are in the src/public/app/widgets/dialogs directory, the import would look as follows:
import { t } from "../../services/i18n.js";
Afterwards, simply replace the hard-coded message with:
${t("msgid")}
where msgid is the key of the message being translated.
Variables
In the translation, enclose the variables with {{ and }}:
{
+ "key": "{{what}} is {{how}}"
+}
Then pass the arguments when reading the translation:
t('key', { what: 'i18next', how: 'great' })
Template-level translations
Templates are .ejs files present in src/views, these are used to prepare the root layout for desktop, mobile applications as well as setup (onboarding) and the shared notes view.
Due to using a different approach, it is not possible yet to translate those files.
Server-side translations
Currently the server-side messages are not translatable. They will be added as a separate step.
Provides context about when the build was made and the corresponding Git revision.
The information is displayed to the client when going in the about dialog.
The build information is hard-coded in src/services/build.ts. This file is generated automatically via npm run update-build-info which itself is run automatically whenever making a build in the CI, or a local delivery.
