I am currently implementing this feature and have most of the functionality ready for vehicles. Regarding "conditional variables and strings" IMHO the most preferable way would be to use a JS template engine that supports an if-else structure, among other possible features that allow advanced use cases when templating an unit / building name.

Do you have any preferences? Quick research:

• LiquidJS, only one additional dependency, last release December 2023 (Snyk)
• Twing, Twig-compatible, last releasee January 2024 (Snyk)

I haven't looked at them in detail but on first sight, it looks like I would prever LiquidJS.
Please keep in mind, that in the end, usage of the Templates should be very easy to use for everyone, plus we should probably add some docs explaining how to use templates (similar to https://docs.lss-manager.de/de_DE/settings.html#moment-js).

I'm not sure if that is already written down somewhere in the chats etc. but to be sure here 2 thoughts for RenameVehicles that are curently in my mind that I would love to be considered:

1. I think users would love some kind of "live preview" when creating their template. Maybe one could think of a field where the user can select a vehicle of current "context" and when changing the template, a preview will be auto-updated to show how the new name would look like for this vehicle
2. Many Users would probably prefer a GUI to design their templates over a simple text-input (especially non-tech-users). This could be done in a future update after initial release but considering the planned logical possibilities (such as conditionals), I think that could be a larger issue than one may think in the beginning.

additional note: A way to import v3 aliases into v4 would be very useful.

additional note: A way to import v3 aliases into v4 would be very useful.

By detecting and importing lssm_LSS_RENAMEFZ_STORAGE from the local storage or modifying the generic import function?

The generic import function would either need to be modified to delegate the import process to the respective modules or have the migration inline. Former one could be quite complex (and OOS for this feature/PR IMHO), later one would introduce module-specific logic into the core.

Use the local storage could be done as simple Vue setting component inside the module which would allow to recurringly import the v3 renameFz settings.

Since between there is a major change between v3 and v4 I won't force this feature.

Maybe an export function in v3 and a script, which converts the aliases to a readable v4 setting

Seems like for importing missionKeywords into v4, I already did some stuff but we never released that: https://github.com/LSS-Manager/lss-manager-v3/tree/missionkeywords-to-v4
I don't even know if it would be ready for release or if something's still missing. Also it's likely that it doesn't work anymore due to changes in LSSMs internal API. But maybe one could use that as a base to add an "export to v4" button for renameFz