Feature request: easier refactoring

[theetrain]

Since message keys are defined in JSON, it's currently not possible to take an expression like m.home_title() and use VSCode's "rename symbol" feature to change home_title to home_welcomeTitle in both the consuming page and source en.json file.

Referencing Discord, I'm guessing there's a plan to allow JS message definitions, such as an en.js instead of en.json to support easier renaming.

[samuelstroschein]

rule number 1: never rename a message. you will break your translations.

@loris.sigrist every feature around naming messages is becoming redundant when we introduce (automatic) human readable ids. i would ignore those issues and reference https://inlang.com/documentation/concept/message#idhuman-readable

[theetrain]

every feature around naming messages is becoming redundant when we introduce (automatic) human readable ids. i would ignore those issues and reference https://inlang.com/documentation/concept/message#idhuman-readable

I checked out the link. Would aliases allow me to reference a message via autocomplete using any of the available aliases? For example, given this message:

const en = {
  id: "banana_car_sky_door",
  alias: {
    default: "login-page-card-title"
    android: "signup-screen-card-title"
    ios: "LOGIN_CARD_HEADER"  
  }
}

Would I be able to type m and then have login-page-card-title resolve to m.banana_car_sky_door? I'd appreciate some clarification on the developer experience. If aliasing does what I think it does - of having multiple IDs refer to the same message - then that certainly helps with the refactoring/renaming dilemma.

Even a basic naming convention that resembles the underlying message is still a good system because the convention will yield the desired copy via autocomplete much more intuitively than a generated id; when I want "Welcome to the store" then I can type "welcome" and see welcomeHeading in autocomplete, rather than have nothing pop up and the corresponding ID being banana.

[samuelstroschein]

Would aliases allow me to reference a message via autocomplete using any of the available aliases?

Yes, but you can only use valid js identifiers. login-page-card-title is an invalid JS variable/function name. it needs to be camelCase or snake_case.

Even a basic naming convention that resembles the underlying message is still a good system because the convention will yield the desired copy via autocomplete much more intuitively than a generated id; when I want "Welcome to the store" then I can type "welcome" and see welcomeHeading in autocomplete, rather than have nothing pop up and the corresponding ID being banana.

Rule number 2: never share messages.

Recycling messages e.g. using welcomeHeading multiple times in code, is bad practice. Here is why https://github.com/opral/inlang-message-sdk/issues/7. We will introduce a lint rule for duplicate messages (that you can activate or deactivate).

@theetrain Given that recycling a message is bad practice, what's the benefit of a naming convention (which will always fail) to get autocomplete for stuff like welcomeHeading?

[theetrain]

rule number 1: never rename a message. you will break your translations. Rule number 2: never share messages. Given that recycling a message is bad practice...

I appreciate you taking the time to go through these. Is there a web page or article I can read to learn about these rules? Paraglide is the first i18n library I decided to use on a major project, so I hope to put my best foot forward in implementation and in conversations like these.

Recycling messages e.g. using welcomeHeading multiple times in code, is bad practice. Here is why https://github.com/opral/inlang-message-sdk/issues/7.

That sounds agreeable. I admit I was withholding details; the name convention I came up with is scope_section_copy so more practical examples are home_title and profile_title; and home_pricing_goldTierHeading and home_pricing_silverTierHeading. They're only used once, the names won't clash, and autocomplete is straightforward/possible.

Having said this, will aliases have similar autocompletion? This is important to me since code reviews, or people not using the Inlang/Sherlock inspector won't be able to see resolved strings inline.

[samuelstroschein]

Is there a web page or article I can read to learn about these rules?

Not yet. We plan to build all those best practices as lint rules (see https://inlang.com/c/lint-rules) to ensure that best practices are followed.

Generally, the knowledge of how to do i18n "correctly" is sparse. Correctly refers to "how can we scale our product to X demographics with the least amount of resources". Most people only think about their perspective e.g. a developer not thinking about problems designers or translators will get (like renaming a key of a message) and vice versa. The result is chaotic i18n processes that take many resources.

Solving i18n for all people involved is exactly what we are striving to solve with inlang: One ecosystem with solutions for every persona in the i18n pipeline (and accounting for their problems!).

Having said this, will aliases have similar autocompletion?

Yes. Aliases are compiled like regular messages but will be marked as deprecated because naming messages leads to the desire to rename them and break your i18n process with designers/translators.

This is important to me since code reviews, or people not using the Inlang/Sherlock inspector won't be able to see resolved strings inline.

What benefit do reviewers have by seeing home_pricing_goldTierHeading compared to happy_human_elephant? It's just an "id", no?

If you reviewers want to see the string, they would have to copy the id and search for it. Regardless, if it's following your naming convention or human readable (aka copyable :D) ids.