personal.info is not language dependent

[hash-josh]

There are certain fields in the personal.info section of metadata.toml where having different values for a key depending on the language would be very helpful. For example the location tag might be different in different languages.

[yunanwg]

Hi, thanks for raising this!

Before I dive into implementation, I'd like to understand your use case better:

1. What specific fields do you need to vary by language? Just location, or others as well?

2. What's the context? Are you generating multiple language versions of your CV from the same source, or is this for a different workflow?

I'm hesitant to add per-field language overrides because it increases configuration complexity - the metadata.toml is already quite detailed, and I want to keep it manageable for new users.

Currently, language-specific values live in the [lang.<code>] sections (like header_quote, cv_footer). One option would be to extend that pattern to allow overriding personal.info fields there. But I'd like to understand if there's a simpler solution that would work for your needs.

Do you have thoughts on alternative approaches? For example:

• Would maintaining separate metadata files per language work for you?
• Is this a one-time need or something you'd use regularly?

Looking forward to hearing more about your use case!

[phil-chp]

Hello!

Thank you for maintaining brilliant-cv, it's a very cool template, I've been considering moving to a Typst CV for a while now and just did recently.

I'm currently facing the same problem. It would be very useful to extend all of personal.info via lang.<code>.

1. What specific fields do you need to vary by language?

For example, I'm French, and in my custom fields I added "Permis B" for the driver license, though that can be a bit confusing in a non-EU job market. Also, it's more common to say "Bac+5" or "Master" instead of "MSc".

And this is not my case, but maybe someone has multiple phone numbers depending on country, and would like to display the correct phone.

There's also an argument for having all of personal be translatable. First and last name can differ in spelling (e.g. different scripts or even anglicized versions of names).

2. What's the context?

I use brilliant-cv the intended way, having completely different sources for each language and building via --input language=<code>.

Would maintaining separate metadata files per language work for you?

That would be cleaner I suppose, If done that way I would also consider injecting language specific keywords on top of the English ones. (Which isn't particularly useful the other way around)

Is this a one-time need or something you'd use regularly?

Occasional when job hunting.

[yunanwg]

Thanks @phil-chp for the detailed use cases — "Permis B" vs "Driver License" and "Bac+5" vs "MSc" are exactly the kind of real-world scenarios that make this clear.

I've been thinking about this more broadly. Rather than adding per-field language overrides to personal.info (which adds complexity to an already detailed metadata.toml), I'm leaning toward a profile system where each profile folder contains its own complete metadata.toml.

This means instead of:

modules_en/
modules_fr/
metadata.toml  ← shared, with [lang.en], [lang.fr] sections

You'd have:

modules_en/
  metadata.toml  ← complete, self-contained
  professional.typ
  education.typ
  ...
modules_fr/
  metadata.toml
  ...

Each profile is fully independent — you can have different personal.info, header_quote, keywords, etc. per profile. And profiles aren't limited to languages — you could have solution-engineer/, data-analyst/, etc. This naturally solves the issue since each profile owns its metadata.

What's your take on this?

[phil-chp]

Hello @yunanwg, interesting, I feel like that's the best approach, though, would you keep a "master" metadata.toml at root? If not we would need to re-apply sections like the layout for all files. Though, more customization might benefit others.

[yunanwg]

Thanks @phil-chp for the great question about a "master" metadata.toml.

After thinking about this more, I've landed on a simpler approach: we'll ship a deep-merge utility function as part of the package.

deep-merge recursively merges two dictionaries — keys in the override win on conflict, base keys are preserved otherwise. So you can keep a root metadata.toml with all shared config, and create sparse override files that only contain what differs.

Example profiles/fr.toml (only the differences):

language = "fr"

[personal.info]
  location = "Paris, France"

  [personal.info.custom-1]
    awesomeIcon = "car"
    text = "Permis B"

In your cv.typ:

#import "@preview/brilliant-cv:4.0.0": cv, deep-merge
#let metadata = toml("./metadata.toml")
#let profile = sys.inputs.at("profile", default: none)
#let metadata = if profile != none {
  deep-merge(metadata, toml("./profiles/" + profile + ".toml"))
} else {
  metadata
}

Then build with typst compile cv.typ --input profile=fr.

This avoids duplicating [layout] across files (your concern), while keeping full flexibility. The template folder is yours to customize — deep-merge is just one building block we provide; the file structure and how you use it is up to you.

Working on a PR for this. Would love to hear if this covers your use case!

[phil-chp]

I ran a quick test, and it works really well!