Extend <language> and <locale> tags

[Jo-Be-Co]

Extend <language> and <locale> tags to allow different outputs like ISO-codes or names in different languages

[Jo-Be-Co]

Hi @rmcrackan!

Have a look at this. I wanted to output language and region as two letter ISO codes.
So I put the appropriate values into the corresponding data type to gain access to this and some more.

User documentation still missing.

[rmcrackan]

At a glance this looks good. Today's my last day before I leave town for a long weekend. I'll give this a better look when I return. Let me know if there are any specific places you'd like extra attention.

[Jo-Be-Co]

Enjoy your weekend. And afterwards:

• isn't <locale> a tag or property that belongs to the library book instead of the book itself? Like <account>?
• Shall we use {I} for two letter ISO codes as well as {I2}?

[rmcrackan]

Enjoy your weekend

Thanks. We had a great time

isn't a tag or property that belongs to the library book instead of the book itself? Like ?

Yes and good catch. The migration and code changes felt like a pain so I just never got around to the fix. It was easy to procrastinate since audible so often uses different asin.s even for the same book in different regions, so the difference is usually academic. You're right though, it does belong in the same place as the account.

Shall we use {I} for two letter ISO codes as well as {I2}?

Sounds good to me.

This looks great. I have a lot to say below but it's all minor:

public static TemplateTags UI { get; } = new("ui", "UI language");
public static TemplateTags OS { get; } = new("os", "OS language");

I'm not necessarily opposed to this, but what's the purpose? It doesn't have anything to do with the books themselves.

Other minutia:

• naming-templates.md : {I3} is described as “Two letter ISO code” in both Region and Language tables; it should be three-letter ISO.
• In the Region row, {ID} is labeled “Lang code”; it should read like region/culture identifier (e.g. US, GB), not “language.”
• Typos: "spcified" -> "specified"; "OS dependant" -> "dependent"
• naming-templates.md : ui, os not listed in the main "Property Tags" table
• RegionInfoDto.GetCultureInfo uses First(). It feels fine. I don't know if an unknown RegionInfo is possible. If so First() would throw. Recommend handling FirstOrDefault()
• In https://github.com/rmcrackan/Libation/pull/1725/changes , CultureInfoDto.cs and RegionInfoDto.cs have warnings. Please address them

Again, just minor stuff. This is a solid PR.

[Jo-Be-Co]

Since some of my recent changes could already work with CultureInfo, my thoughts naturally turn to possible applications such as ´<set-lang 'fr-CA'-><title[U]> (<language[{N}]>)<-set-lang>` ...

Here, the two lang settings OS and UI already come into play if no other settings are specified. However, these two tags are actually more of an informational nature – which is why I haven’t documented them in any further detail yet.

The other parts are all good spots - I'll address them shortly.

[Jo-Be-Co]

With the changes I am working on for #1714 you might use OS and/or UI to add language details to the path only if they differ from local setting:
...\<title><cmp language[{I}] != os[{I}]-> @<language[{I3}]><-cmp>\...

[rmcrackan]

Gracias. Is this ready for merge?

[Jo-Be-Co]

If that’s all right, the <os> and <ui> elements haven’t been documented in detail yet...

[rmcrackan]

Oh, right. I see you're reasoning for not doing so. It just feels weird to have so much good documentation for everything else then leaving these out. I think I'd like to see them included.

[rmcrackan]

The move of Locale from Book to LibraryBook is a real schema change: today Locale lives on Books, not LibraryBooks. The PR updates the EF model but does not include migrations, so existing databases will fail at runtime. Please add SQLite and Postgres migrations that

1. add LibraryBooks.Locale
2. backfill from Books.Locale via BookId
3. enforce nullability as needed
4. optionally drop Books.Locale

Please test upgrading from an existing DB file.

[Jo-Be-Co]

oh dear. That is going bigger than I thought it would be.
Maybe I should undo this for the sake of this pull request and have a look at it separately.

[rmcrackan]

I think you can handle it, either here or in a diff PR. A separate PR does sound sensible for isolating this DB change though.

Basically: Add migrations for both databases (SQLite and Postgres). dotnet ef migrations add should do the heavy lifting. After EF creates the migration, add a SQL UPDATE to copy Locale from Books to LibraryBooks by BookId before dropping the old column. And test the hell out of it because if the Migrate Up doesn't work, I'm not sure I would trust the Migrate Down to roll it back.

[rmcrackan]

And I'm here for questions and help.

[Jo-Be-Co]

OK - refactoring of locale property undone for this PR

[rmcrackan]

Looks great. I'm ready to merge. Anything else you'd like to add before I mash the button?

[Jo-Be-Co]

Well, guess what. I’ve found another place where special cases like “pre-amazon” are predefined: AudibleApi.Localization
Now I’m using this information to map to the country. The ID for locale is now the marketplace ID, and you can also output {L}anguage and {T}oplevel domain!

[Jo-Be-Co]

That's it! Unless you'd like something tuned 😉

[rmcrackan]

AudibleApi

I'm sure it won't surprise you to know that this used to all be 1 big solution. I broke AudibleApi into its own repo/nuget when developers expressed interest in using it without Libation. I tried to cleanly break up the 2 but as you've found, there are still residual parts where I probably could have done better.

[rmcrackan]

That's it!

Awesome. Thank you so much. This is another great looking change set. Merging now.