International Support

[bpepple]

Expanding Metron's International Publisher Support

Metron currently only supports US publishers, but there is a growing interest in expanding coverage to publishers from other countries. So, it's time to have a discussion about it: what does proper international support look like for the project?

What's currently in place

• The publisher form validates against a US-only allowlist
• USD is the only supported currency

What we'd like to discuss

Expanding international support will likely touch several areas of the application, and we'd love community input on what matters most. A few things we've already identified:

• Countries — The publisher form currently only accepts US publishers. We need a policy for how we expand this: open it up entirely, maintain a curated list, or gate additions behind a request process. Given the number of significant UK publishers (2000 AD, Titan Comics, etc.), adding GB support would be a natural first step. We already have a draft PR (Add UK publisher and GBP currency support #514) in progress to add UK support as an initial candidate.
• Currencies — django-money supports many currencies; we need to decide which to enable and whether price display should be locale-aware. GBP would be the logical companion to any UK publisher support.

What else needs consideration?

Some areas we haven't fully explored yet:

• Date formatting (day-first vs. month-first conventions)
• Language/locale metadata on series or issues (e.g. non-English publications)
• Publisher name transliterations or alternate scripts
• Timezone handling for release dates

We'd welcome input from anyone who has data to contribute or uses Metron for non-US comics. What publishers or regions are you most interested in seeing supported, and what data or UI changes would make that work well?

[allaboutduncan]

Rough draft of my thoughts and happy to dig deeper into any of these. Some informed by work I did long ago on multiple sites that were translated into 15+ languages and how we handled those translations on a DB level.

Countries

For Countries - I think it should be gated behind a request process, but I'm also guessing that depends on where/how you're getting metadata for series/issues/etc.

100% think UK/GB would be the obvious one to start, but after that, I wouldn't want to see a bunch of countries added, series added, only to have issue data be lacking because you can't scrape it and users don't add it.

Using a request process would also let us enable corresponding currencies as countries are added.

Currency

For Currencies I would think providing the raw data (amount and currency code) would suffice. Let the user / app format set on the front end. So if we add a UK publisher, when they're added, we set the default currency for them as well.

Date Formatting

Date Formatting - It looks like you're using ISO 8601 currently (from what I can see in the /issue_list response for cover_date and I see no reason to deviate from that. Similar to currency, we could set a default format for date in publisher. MM-DD-YYYY for US and DD-MM-YYYY for UK

Timezone Handling for Release Dates seems the most straight-forward. For these, I would just use the timezone-naive date (YYYY-MM-DD) in the ISO format.

Language and Locale

Language and Locale Metadata Many years ago I did a LOT of work on a multi-national site that was translated to 15+ languages. I would recommend the IETF BCP 47 language tag format. It allows you to get very specific, if needed. For example, there is Brazilian Portuguese (pt-BR) as well as European Portuguese (pt-PT).

Additionally, it would likely be handy to have a Series Level original_language to track the publication language. Then on the Issues we could have language and region which are combined for the BCP 47 code (Brazilian Portuguese (pt-BR)).

May be too much, but future proofs for any use case.

Transliterations and Aliases

For Publisher name transliterations or alternate scripts this one has me a bit stumped and I would be interested in hearing what you think @bpepple - this will have the most impact on the API and what/how users search. How do we integrate this with the existing API and structure. Here's what would make sense, but not sure how to map to the API:

• Primary Name: The name in its native script
• ** Transliterated Name:** A standard Latin-character version for English-speaking users or systems that do not support complex scripts
• Aliases/Sort Name: Other names for the series

[bpepple]

Countries

For Countries - I think it should be gated behind a request process, but I'm also guessing that depends on where/how you're getting metadata for series/issues/etc.

100% think UK/GB would be the obvious one to start, but after that, I wouldn't want to see a bunch of countries added, series added, only to have issue data be lacking because you can't scrape it and users don't add it.

Using a request process would also let us enable corresponding currencies as countries are added.

I think a request process is the way to go, also. We should define what criteria to use in the decision making to add a new country. Maybe, consider thing like this:

• How established the publishers are? Are they a long running publisher or something that's only been published by a kick-starter or other small press?
• Strong support from the Metron community?
• ???

Currency

For Currencies I would think providing the raw data (amount and currency code) would suffice. Let the user / app format set on the front end. So if we add a UK publisher, when they're added, we set the default currency for them as well.

Date Formatting

Date Formatting - It looks like you're using ISO 8601 currently (from what I can see in the /issue_list response for cover_date and I see no reason to deviate from that. Similar to currency, we could set a default format for date in publisher. MM-DD-YYYY for US and DD-MM-YYYY for UK

Timezone Handling for Release Dates seems the most straight-forward. For these, I would just use the timezone-naive date (YYYY-MM-DD) in the ISO format.

What we currently have in place for currency & date handling seems sufficient.

Language and Locale

Language and Locale Metadata Many years ago I did a LOT of work on a multi-national site that was translated to 15+ languages. I would recommend the IETF BCP 47 language tag format. It allows you to get very specific, if needed. For example, there is Brazilian Portuguese (pt-BR) as well as European Portuguese (pt-PT).

Additionally, it would likely be handy to have a Series Level original_language to track the publication language. Then on the Issues we could have language and region which are combined for the BCP 47 code (Brazilian Portuguese (pt-BR)).

My thinking is that we need to take into account the scope and use of the language field, specifically in regards to comics rather than how it relates to the site itself.

In this instance, we are using the information to determine what language the comic is written in, which is the scope and purpose of ISO 639-1 — a standard that tends to be used in databases and API responses.

If we were using the language purely for web technologies, such as HTTP headers or localization settings for the site, BCP 47 would be the obvious choice, since it allows more precise identification of language preferences for users in different regions.

Transliterations and Aliases

For Publisher name transliterations or alternate scripts this one has me a bit stumped and I would be interested in hearing what you think @bpepple - this will have the most impact on the API and what/how users search. How do we integrate this with the existing API and structure. Here's what would make sense, but not sure how to map to the API:

* **Primary Name:** The name in its native script

* ** Transliterated Name:** A standard Latin-character version for English-speaking users or systems that do not support complex scripts

* **Aliases/Sort Name:** Other names for the series

So, we could add an alias field (most likely an ArrayField) to the Publisher model, and add that as another param. A better solution would be to use the name and alias field when searching the Publisher endpoint when using the name param. I'm not certain we would even need a Transliterated Name field since I think the alias field be used.

[Aroy-Art]

One thing that also needs to be dealt with somehow is that some publishers (e.g. Europe Comics) are a collections of publisher so its more over a region than a country

https://en.wikipedia.org/wiki/Europe_Comics

[bpepple]

One thing that also needs to be dealt with somehow is that some publishers (e.g. Europe Comics) are a collections of publisher so its more over a region than a country

https://en.wikipedia.org/wiki/Europe_Comics

Do you know how many Publishers are like that? If not many, I'd lean towards not assigning a country.

[Aroy-Art]

I can only think about two top of my head

I wounder how musicbranz handles it for there metadata

[Aroy-Art]

https://musicbrainz.org/doc/How_to_Add_a_Release

here is a little bit of info in the top part, but not much more that i can find

[bpepple]

So, after a bit of search-fu this seems like a fairly uncommon situation and I'm inclined to keep our current handling instead of implementing a work-around. Glanced at how the other sites handled it. CV doesn't set a country, while GCD uses Belgium.

[bpepple]

Proposal: Phased International Support for Metron

Based on the discussion so far, here's a proposed approach broken into phases.

---

Phase 1 — UK/GB as the Pilot (PR #514)

Merge the existing draft PR to add UK publisher and GBP currency support. This gives us a real-world test case to validate the broader approach before opening the floodgates.

---

Country Expansion Policy

New countries should be added via a gated request process, not open enrollment. A request should meet criteria such as:

• The publisher is well-established (not a one-off Kickstarter or small press)
• There is demonstrated interest/support from the Metron community
• Sufficient metadata can realistically be sourced or contributed (to avoid half-populated entries)

For the small number of publishers that span multiple countries (e.g. Europe Comics — roughly 2 known cases), we may need to do some investigating on how to add them. For example, Europe Comics country is set in Belgium since they initially began there and Comic Vine just leaves if blank.

I'm about to add a polling app to the site that we could maybe use to have the community vote on whether to add any new request for a country.

---

Currency

django-money handles this, and we will just need to add new countries to the site's settings to enable them/

---

Date Formatting & Timezone

Continue using ISO 8601 (YYYY-MM-DD) for all dates — the API already does this and it's the right call. Dates should remain timezone-naive for cover/release dates. No changes needed here.

---

Language & Locale Metadata

Use ISO 639-1 language codes (e.g. en, fr, pt) for comic content metadata — appropriate for database/API use where simplicity matters. This can be added after Phase 1, when we add a non-English speaking country.

Suggested model changes:

• Series: add original_language (ISO 639-1 code)
• Issue: add language field (ISO 639-1 code) for translated editions

BCP 47 is better suited for UI/localization concerns (HTTP headers, site language settings) and would be overkill for comic content metadata at this stage.

---

Publisher Names & Transliterations

Add an alias field (likely a Postgres ArrayField) to the Publisher model to handle:

• Transliterated names (native script → Latin characters)
• Alternate names / sort names

The name search on the Publisher API endpoint should search across both name and alias fields. A separate dedicated transliterated_name field is probably unnecessary if alias covers the use case.

---

Summary of Model Changes

Model	Field	Type	Notes
Publisher	alias	ArrayField	Transliterations & alt names
Series	original_language	CharField	ISO 639-1
Issue	language	CharField	ISO 639-1, for translations

@allaboutduncan @Aroy-Art Is there anything you can think of that is missing?

[bpepple]

Welp... haven't heard any objections to the plan, so I'll start implementing it.