You can contribute to this plugin translation. Translations are handled using the Weblate software, using Framasoft Weblate instance.
Never modify directly files in the languages folder, this could lead to conflicts.
There might be some «very technical» strings. If you are not 100% sure of the meaning, or of your translation, you better not translate it, so it will display in english.
This plugin relies on ConverseJS for the chat front-end. ConverseJS has its own translations, on its own weblate instance. You can also translate directly in the code repository. For more information, check ConverseJS translations documentation.
If you think there is a missing locale, please check first if it is handled in Peertube. If so, you can open an issue to ask for it.
If you are working on new features, and need new strings, you can create them directly in Weblate. The english version is mandatory. Start with it.
Each string is linked to a key (for example use_chat).
Choose an explicit key in english, lower case.
If you have to test new strings without waiting for a Weblate merge, you can modify languages/*.yml files,
but avoid to commit these changes (to minimize conflict risks).
Before using a string in front-end, you need to declare a new constant in client/@types/global.d.ts.
The constant name must:
For example, to use “use_chat”, you have to declare:
declare const LOC_USE_CHAT: string
The build-client.js script will read the client/@types/global.d.ts,
search for such constants, and load their values from the languages files.
Now, you can simply call peertubeHelpers.translate(LOC_USE_CHAT) in your code.
In theory, the only parts of the backend code where you need localization is the settings declaration and standardized data (ActivityPub, RSS, …). Here we need to get english strings from the translation key.
Note: you should never need another language translation from backend code. Localization must be done on front-end.
There is a lib/loc.ts module providing a loc() function.
Just pass it the key to have the english string: loc('diagnostic')'.
The documentation translation is done using the corresponding Weblate component.
There is a specific “Hugo shortcodes” you can use to display an application string. Saying you want to display the name of the button “open_chat_new_window”, you can use this in the documentation markdown file:
{{% livechat_label open_chat_new_window %}}
You can also prevent a whole page from being translating by adding livechatnotranslation: true in the Yaml Font Matter section:
---
title: "Third party"
description: "Displaying the livechat with 3rd party software."
weight: 20
chapter: false
livechatnotranslation: true
---
Never translate a string in the livechat.en.pot file, it would be ignored.
Instead, edit directly the markdown files.
If a string contains a link, you can change it for the correct link in the translated language. For example, for a link to this documentation, you can add the language code in the url.
Some strings are block of code. Don’t translate code. But you can translate comments, or parameters if relevant.
If you are not sure, just don’t translate, and ask what to do.
The tool I use to handle translations for the documentation can have strange behaviours. When I add sentences that looks like other existing sentences, it sometimes copies existing translations. So, when you have translations marked as “to check”, please make sure it doesn’t copy a string that has nothing to do with the english one before validating.
If you are now sure about the context of a string, you can check the string location in the weblate’s right pane, and open the corresponding documentation page.
For example, for a string located in the file support/documentation/content/en/documentation/user/streamers.md, the corresponding url is https://livingston.frama.io/peertube-plugin-livechat/documentation/user/streamers/.
Please be inclusive in your wordings, and please respect the code of coduct.