Feature Request: Add official Polish translation support

[Yabi23]

Hello!
I have created a Polish translation module for the Cloud Commander interface (including MenuData and Messages).

You can find my repository here: https://github.com/Yabi23/cloudcmd-pl

Could you please add it to the official cloudcmd organization so it can be natively supported in the future releases? Thanks!

[coderaiser]

It wouldn’t work as it is, we need to integrate 18n architecture layer, do u have any ideas how to do it?

[Yabi23]

Thanks for the quick response!

Since Cloud Commander is built on Node.js/JavaScript, we could introduce a lightweight i18n framework like i18next or a custom built-in system that loads JSON dictionary files dynamically based on the browser's locale or the LANG environment variable.

However, to keep it as simple as possible without adding heavy external dependencies, we could structure it similarly to how the core plugins handle configuration:

1. Move the current hardcoded English strings from the components into a default en.json file.
2. Create an internal localization utility module that checks the global configuration and merges/overrides the strings with the selected language pack (like the pl.json or cloudcmd-pl module).

I would love to help with this! Do you prefer a specific lightweight library, or should we aim for a minimal, native custom loader for the JSON translation layers?

[coderaiser]

let’s define shape that works in both: i18n and lightweight library, so we can switch

[Yabi23]

A flat key-value JSON structure where the English string acts as the key would be the most versatile and future-proof "shape". It works out-of-the-box with i18next (using it as a fallback language) and can be easily parsed by any minimal custom loader.

Here is a proposal for the structure (pl.json):

{
    "F2 - Rename": "F2 - Zmień nazwę",
    "F3 - View": "F3 - Podgląd",
    "F4 - Edit": "F4 - Edytuj",
    "F5 - Copy": "F5 - Kopiuj",
    "F6 - Move": "F6 - Przenieś",
    "F7 - Make Directory": "F7 - Utwórz katalog",
    "F8 - Delete": "F8 - Usuń",
    "Cancel": "Anuluj",
    "Ok": "OK",
    "Close": "Zamknij",
    "Save": "Zapisz"
}

By exporting it as a clean JSON object, a lightweight custom switch function could look like this:

const t = (englishString) => {
    return currentLanguagePack[englishString] || englishString;
};

This setup gives us full flexibility: we can easily drop in an external framework later, or stick to a zero-dependency custom helper for now. What do you think about this shape?

[coderaiser]

looks good, this minimal approach is perfect, how it will be reflected in codebase? what files needed to be changed?

[Yabi23]

To implement this cleanly, we would need to touch a few key areas in the codebase:

1. Translation Dictionaries (json/ or common/json/):

   • Extract current hardcoded strings into a baseline en.json.
   • Add language files like pl.json in the same directory using the flat key-value format we discussed.

2. Localization Helper (server/ or common/):

   • Create a small helper function (e.g., t.js or inside an existing utility module) that detects the system language via process.env.LANG or configuration settings, loads the matching JSON file, and exports a global translation function:

     const t = (str) => currentPack[str] || str;

3. UI / Components (client/modules/ and server/):

   • Update components where strings are currently hardcoded (like context menus, configuration modals, or copy/move operation alerts).
   • Replace literal strings with the wrapper function, for example:
     • Before: 'F2 - Rename'
     • After: t('F2 - Rename')

By keeping it this simple, we don't break any existing logic, and adding support for any new language in the future will literally just mean dropping a new .json file into the folder.

How does this plan sound? I can help map the exact locations of hardcoded strings if you want to point me toward the preferred module for the helper function!

[coderaiser]

1 json
2 common

Sounds good, point files we going to change, directory where translations located json/i18n?
I think would be also great to add option (what is better name for it?) and drop-down in config to choose from the list.

[Yabi23]

The directory json/i18n sounds perfect and keeps everything highly organized!

Regarding the dropdown in the configuration menu (F10), adding it is an amazing idea. For the option name, "Language" is the most standard, clean, and globally understood term.

To make this happen, here are the main files we need to update in the repository:

1. json/config.json:

   • Add a new default key: "language": "en" (so it falls back to English out-of-the-box).

2. client/modules/config/index.js (or the corresponding configuration view file):

   • Add the new "Language" dropdown field into the template layout.
   • Bind it to the configuration state so changing the value updates the server/client config.

3. client/json/menu.js and client/json/messages.js:

   • These are the exact hardcoded files we need to convert into templates or load via our translation helper in json/i18n/.

I think we should start by creating json/i18n/en.json and json/i18n/pl.json in the codebase first. Would you like me to open a Pull Request with the initial translation files and the helper function, or do you prefer to set up the base i18n module structure first?

[coderaiser]

Let’s setup structure first, so we have common/i18n.js and json/i18n/

client/json/menu.js and client/json/messages.js:

What is this for?

We set language like this?

cloudcmd —-lang pl

And CLOUDCMD_LANG_PL

Or you want add also autodetect?

[Yabi23]

The proposed file structure (common/i18n.js and json/i18n/) looks incredibly clean and logical!

Regarding the language configuration, supporting both options (CLI/Env variables and Autodetect) would be the best approach.

Here is how we could handle the priority order for maximum flexibility:

1. Explicit configuration (Highest priority): If a user specifies --lang pl, an environment variable like CLOUDCMD_LANG=pl, or changes it in the F10 configuration menu, this should always take precedence.
2. Autodetect (Fallback): If no explicit configuration is provided, the application should automatically detect the language on startup:
   • On the server side: by parsing the LANG environment variable (e.g., pl_PL.UTF-8).
   • On the client side (browser): by checking navigator.language.

Regarding client/json/menu.js and client/json/messages.js, those are the exact files that currently hold the hardcoded UI strings. We will migrate their contents into the json/i18n/ directory so they can be loaded dynamically through common/i18n.js.

I can start drafting the core logic for common/i18n.js to handle this lookup and autodetection. Should I proceed and create the base files?

[coderaiser]

1 good
2 we can create i18n on client and i18n.js on server, I think we can skip autodetect to next phase

There is no such file in repo right now client/json/menu.js

I have a question about languages: we import all at once to client bundle? Or choose only what neaded? Or dynamically load it, or embed on server side?

[Yabi23]

1. Sounds perfect, keeping autodetect for the next phase is a great way to deliver a stable MVP first.
2. My mistake regarding client/json/menu.js – if the strings are currently hardcoded directly into the component files, we can extract them into the JSON files during the refactoring process.

Regarding the loading strategy, dynamic loading (fetching only what is needed) or embedding it on the server side would be the cleanest and most performance-friendly solutions.

Since Cloud Commander aims to be lightweight, we should definitely avoid importing all languages at once into the main client bundle, as it would unnecessarily increase the bundle size for every user.

I propose embedding the selected language data or localization config directly from the server side on initial load, or letting the client context issue a clean dynamic fetch() request for the specific JSON file (e.g., await fetch('/json/i18n/pl.json')) right when the app initializes.

Dynamic fetching keeps the client bundle entirely decoupled from the language asset sizes. What do you think about going with dynamic JSON fetching for the client side?

[coderaiser]

Can you write some kind of rfc similar to https://github.com/eslint/rfcs

I see the need of i18n and agree to add it, but there is lots of details and better to think beforehand about them, because in other case I will left one-on-one with this feature. You OK to support it in future when someone want to add other translation will you help with this?

[Yabi23]

I completely understand your point, and I think writing an RFC is a fantastic idea to map out all the details before touching the actual code. We definitely want this to be maintainable and robust.

To answer your question: Yes, absolutely! I am more than happy to support this feature in the future and help other contributors integrate new languages into the i18n structure we build.

I will prepare a detailed RFC draft following the standard format (Motivation, Detailed Design, Directory Structure, and API shape) and share it with you here shortly so we can review all the edge cases together.

Stay tuned!