#Knossos internationalisation support

1 messages Ā· Page 2 of 1

lucid belfry
#

nuxt why

#

actually I think I know the reason before connecting debugging

#

common f--king js

#

and vintl is esm only module, so it imports esm build of vue

#

PLEASE

#

KILL

#

CJS

#

I cannot overstate how much pain it causes to continue to support it

lucid belfry
#

after putting vintl into transpile it works

#

however it still bothers me so much that nuxt 3 which advertises itself as esm has such issues with esm only modules

lucid belfry
#

wondering if there's a way to do that before the build even started, probably not

#

if there was a way then I could've automagically disable prefetches for these

#

github search been down for a day already

#

very useful thanks github

#

even TP is not working T_T

lucid belfry
lucid belfry
#

and so he did...

#

no prefetches for other locales and their imports/resources šŸ‘

#

also locales and their resources load in parallel!

arctic pulsar
#

nice!!

lucid belfry
# lucid belfry

now that I keep track of all imports I wonder if I can also embed my rollup-plugin-icu-messages to pre-compile messages and yeet the parser out of runtime (prolly on production only)

lucid belfry
#

okay I'll be honest, nuxt module DX sucks --s

#

this weird structure where you have to run dev:prepare for it to generate typescript file that directly depends on the playground

#

just why

lucid belfry
#

okay I probably can avoid this madness by doing it manually

#

don't mind my CWD at this point, I'm losing my mind in this chaos too

lucid belfry
#

okay that's kind of getting somewhere

lucid belfry
#

I have no clue how to manage versions with monorepos tho

#

haven't really figured out changesets and semantic-release doesn't support monorepos

lucid belfry
#

doing manual resolution I actually made something incredible that I didn't even realise —

lucid belfry
#

so I'd want to make sure, do you think it makes the most sense to resolve import from the rootDir (which is usually the directory where nuxt.config.ts is located) or srcDir (if set; which is the directory where all source files for the nuxt app are located, and it matches rootDir if not defined)

#

find it kind of annoying that you cannot easily find nuxt.config.ts location to resolve against it, which would make like the most sense I feel

lucid belfry
#

I just added resolveDir option which is set to srcDir by default, and if set to relative path, will resolve against it

#

anyway

lucid belfry
#

it's funny cause days ago I was wondering how can I make it possible to ship translations in component libraries. so now you can just import messages from something like @scope/package/lang/en-US.json in addition to your regular messages

#

or better just use extendOptions hook provided by the module and auto-add these

lucid belfry
lucid belfry
#

so current HUGE blocks:
🟧 Nuxt not supporting modern node resolution, causing problems with modern packages that define exports (it's more of expectation vs reality problem for typescript, rather than the nuxt itself)
has PR: https://github.com/nuxt/nuxt/pull/18431 Ā· v3.3 Ā· more than 1 month old
🟄 @nuxt/module-builder building runtime with mkdist which doesn't properly convert typescript .js imports (because typescript assumes you WILL use .js extension even though most tools compile to mjs because node.js is obnoxious; and there is no way to tell typescript to enforce mjs (only manually declaring each .js import and then land in a mental hospital))
no submitted pull requests or issues

additional issues:
🟦 import-meta-resolve has circular dependency causing jiti (nuxt ESM to CJS thing) to go nuts || well it just crashes with stack overflow ||
it only harmful for the module users cause it means you can't pre-compile messages using icu-messages rollup plugin and remove the parser
https://github.com/unjs/jiti/pull/125 Ā· merged Ā· not in nuxt
🟄 astring not exporting its type declaration properly
has PR: https://github.com/davidbonnet/astring/pull/668 Ā· untriaged Ā· 3 months old

current state:
most of the things are ready, only need to resolve the blocks and then can start preparing for publishing (really need to learn changesets)

lucid belfry
lucid belfry
#

a

#

I once again here to tell that CJS must die

#

anyway

#

german. or green bird kills me instead

stable lark
#

it is really quite shocking that cjs is actually a thing in 2023

#

I wish all package maintainers would just go nuclear and remove all cjs support from their stuff and refuse to provide any support, it's kinda ridiculous

lucid belfry
#

CJS on its own is not a problem, it can be safely used from ESM (at least in Node.js and with a transpiler). the problem is dual packaging, when multiple versions of the same package can be imported by mistake

lucid belfry
#

to sit one hour looking at screen trying to figure out how to start and absolutely nothing comes to my head. I hate it, so discouraging

#

very envious of people with wide imagination and healthy attention spans

lucid belfry
#

I absolutely love past me who decided to implement this

#

like no /s, this is so helpful

lucid belfry
#

chatgpt said ā€˜make your nuxt app speak languages’ slogan is boring

#

losing my mind right now, my pillow isn't recovering from this tonight

#

😭

last hemlock
#

"make the Nuxt trees speak Vietnamese"

lucid belfry
swift raft
#

Got access to bing last night, here's what it suggested after a bit of prompting

lucid belfry
#

there's also one card hidden because it would be a lie if it was displayed

#

I want to convert my rollup plugin to unplugin so it works with both vite and webpack, shouldn't be hard, but not right now

#

those were suggestions by chatgpt but its texts were kind of eh so I just improvised

#

ehhhhhh I'm so bad at creative stuff

stable lark
#

wow, I've never heard of unplugin, that's pretty cool

lucid belfry
#

oh god vintl developer ends today

#

what do I do with the rest of my time

#

ā€˜you have 1 hr to live’ problem

lucid belfry
#

vercel

#

when you create a team they force you to sign up for a trial

lucid belfry
#

I want to cry so badly /nsrs /hj

#

nuxt claims to be esm first framework
uses old garbage node resolution
doesn't understand .mts extension

lucid belfry
lucid belfry
#

out of context attempt at memes

#

I will split my changes into smaller commits I will split my changes into smaller commits I will split my changes into smaller commits I will split my changes into smaller commits I will split my changes into smaller commits …
@

lucid belfry
#

it respects current query params too, though I have no clue if they updated reactively or not ioa

#

actually now that I look at this picture I see a mistake in x-default

#

now we're talking

final tangle
#

Out of curiosity, besides translations for newer things, what else is left?

lucid belfry
#

hm?

final tangle
#

For knossos to have internationalisation support

lucid belfry
#

since we switched to nuxt 3, I've been focusing on making a proper module, and been working on it all this time, however hard it is. I am getting somewhat close to finishing it, and then I guess it's all work on publishing it, testing if it works in different modes (e.g. serverless deploys), connecting it to knossos and libraries, and then slowly making things translatable. currently I think I have to write docs on how to even use this stuff, and also implement automatic locale files discovery and types generation || šŸ’€ ||. seo, multiple message files, different message files formats (most if it) support, resources, parserless mode (most of it), config validation, these things are finished

lucid belfry
#

automatic messages discovery is an idea where basically module would go through all or defined node_modules or folders, access special config file and according to it automatically register the locale files, resources and imports, as if they were in the main nuxt config, this is supposed easy the burden to manually adding and configuring a bunch of locales, just like discovery: { sources: ['@scope/pkg'] }. I'm yet to figure out the details and most probably going to make first release without it, as it can be imitated much easier. it's all in the air right now, I don't even know how that config file could look like

#

dunno if that message made sense, I'm very sleepy

lucid belfry
#

I maybe hate nuxt a lil bit

echo bronze
#

Maybe this has been asked already

#

but why doesn't this use already available modules?

#

namely @nuxtjs/i18n v8 ?

lucid belfry
#

I don't really like vue-i18n interpolation, especially for plurals, and it requires some manual intervention to properly set up. @formatjs/intl handles lots of stuff for you by using browser APIs and standard ICU MessageFormat syntax for messages

echo bronze
#

Off topic: I wonder why gettext isn’t an option in the web

#

Although I guess its simply harder to use

lucid belfry
#

right, I need to fix the embed

rose knoll
#

why am I now only discovering awesome documentation generators

lucid belfry
#

scroll to the very bottom

rose knoll
#

yeah I saw

#

docus

#

very nice

echo bronze
#

I would’ve suggested VitePress instead, because it’s less rough around the edges in general, but there’s no need to switch

lucid belfry
#

vitepress is really cool, but I used docus because I wanted it to look similar to nuxt docs

#

also I love that it uses nuxt content module which automatically creates trees and stuff

#

in vitepress you need to create sidebars manually

echo bronze
#

It’s just taste probably, but I like VitePress theme a lot more :)

#

I don’t like screen-wide pages (and there’re good arguments against those, I’ve even found a scientific article to convince to make Fabric wiki narrower)

#

Though Docus does come with a narrow page mode

lucid belfry
#

um, wdym, it uses it by default for content pages

echo bronze
#

Maybe it has changed? Last time I tried it, it was the reverse

lucid belfry
#

except for changed accent colour and fix for landing page title

lucid belfry
# lucid belfry vitepress is really cool, but I used docus because I wanted it to look similar t...

vitepress is much simpler and lightweight, I like it for that, so if you just need a doc site for your library, I would literally scream that you use vitepress. but if you need a fancy doc site that looks p r o f e s s i o n a l ✨ and not against the whole nuxt baggage that comes with it, like in this case, this is a library for nuxt, so most of nuxt stuff is already installed, then docus is pretty decent

#

|| anyway completely unrelated but what if.. just what if... knossos used nuxt content module for pages like rules and stuff ||

echo bronze
lucid belfry
#

no I wanted to propose that

echo bronze
#

Though I would propose a separate subdomain/path/app

lucid belfry
#

nah no need really

echo bronze
#

Not really, but it would debloat Knossos a little

#

Do we need more dependencies there?

#

I don’t think so

#

Especially not chunky bois like content

#

Could be combined with the blog:

#

Nginx or traefik will just silently reroute subdomains to paths on a single app

lucid belfry
lucid belfry
#

probably nothing

last hemlock
#

yeah just casually looking into the netzwerkanforderungsblockierung

lucid belfry
#

:KEKW:

echo bronze
#

so adding this to the nuxt config:

export default defineNuxtConfig({
  routeRules: {
    '/legal/**': { static: true },
  },
})

should make the legal pages static

lucid belfry
#

I am not sure what this has to do with dependencies

echo bronze
#

Nothing

#

it's an alternative way to do this

#

or well, an additional step

#

Also, it could be done right now

lucid belfry
#

forgot that nuxt uses legacy resolution

#

annoying af

#

because this will totally work, everyone — node, vite, and webpack — respect it

#

but typescript be like ā€˜na-ah, please use old raw resolution’

#

which won't work!

#

and you can't change this easily because nuxt will break

#

it was available long before nuxt 3 was released, why didn't they use it !

#

ā€˜nice to have’ priority

lucid belfry
echo bronze
#

If TS doesn't like it, it's very possible it's a bad idea

lucid belfry
#

no, see, they use moduleResolution node, which is a resolution mechanism before <16, where by default it would be either / or ./ for path, and [package name]/ for path within package

in node 16 exports field was added to package.json, it allows to create a custom map of exports, which creates ā€˜virtual paths’. so if you have export map like json { "." { // "types": "./dist/index.d.ts", // <- bad! should have. d.mts and .d.cts files instead and never use this field "import": "./dist/index.mjs", "require": "./dist/index.cjs", }, "./other": { // "types": "./dist/other/index.d.ts" "import": "./dist/other/index.mjs", "require": "./dist/other/index.cjs" } } if you import my-package/other it would import node_modules/my-package/dist/other/index.mjs (in ESM)

this has became the default mechanism in node16+ and replaced unofficial fields in package json like module, which were never supported by node

typescript added support for this very shortly, but you need to opt in into it by using moduleResolution node16 or nodeNext. nuxt is node16+ and uses vite, so it must use this resolution, but they don't, which creates problems like above where typescript excepts you to do the wrong thing, because it things it's correct

most bundlers also respect this resolution mechanism, but have some of their weird quirks, like being able to import .ts files, for which typescript added bundler resolution in typescript 5

echo bronze
#

thanks for a reminder for why have i been looking into Symfony and Vaadin šŸ˜…

lucid belfry
#

wha

echo bronze
#

frameworks that don't have JS

lucid belfry
#

meh

echo bronze
#

or to be precise, that do JS the old way

lucid belfry
#

JS is getting better and better, but this transition to ESM was really painful and not everyone caught up yet

echo bronze
#

JS isn't bad, but man is it not good either

#

it's a necessary evil of sorts

#

an ugly child of 2000s browser wars

#

(yes, i know when it was created and by whom)

inner frost
#

Is there a current beta site where translations are available?

lucid belfry
#

no, not really, nothing has been implemented yet

lucid belfry
#

I didn't realise nuxt plugins and generated files are now hot replaceable

#

in nuxt 2 hot variable was never available in them

#

this is cool, means I can reload settings and messages on the fly

#

or

#

no, I don't think I can regenerate files from module, but at least I can accept new messages and resources

lucid belfry
#

this is a restart of restart

last hemlock
lucid belfry
#

ooh did I forget to extract frogged people

last hemlock
#

could you give a brief outline on what the PR-merging side of things looks like right now? I assume it's still fairly similar to what's been put in the PR description but I know it's a bit outdated

lucid belfry
last hemlock
#

the process of getting i18n out on production between now and a release post

lucid belfry
#

I decided to leave the PR barebones so, so it's almost* ready to merge like this to master, given that the master is now staging (iiuc?). I should've marked it as a draft for a bit, though

the reason not to include anything else is that it all can be added progressively, rather than trying to do everything or many things at once and end up with a lot of merge conflicts to resolve. progressively updating piece by piece has advantages that it can be tested that it works, and it's much easier to review and bikeshed (e.g. ā€˜make landing page translatable’)

basically not much has changed by this PR besides some code being added to builds and some modifications to frog page to test that the stuff works. language switcher and other stuff will be in separate PRs

the process of merging is even easier now: merge ⇒ connect crowdin (or don't for now) ⇒ you're ready. no need for separate branches and stuff. and since master is staging now, it's much easier to accept contributions too, no need to separate branches or enabling crowdin for different feature branches (unless you want to get translations before staging?), etc

* saying almost because as you can see for example frog page is a bit broken (apparently vite removes side effect only imports when building nitro server and I need to figure out how to avoid that) :P

last hemlock
#

master is now staging
yes

so once you fix the frog page this PR is ready to be merged, is what you're saying?

lucid belfry
#

yeah, unless something would need to be changed

last hemlock
#

ok, sounds great!

lucid belfry
#

mmm found bug in nuxt

lucid belfry
#

@last hemlock try deploying latest commit||, it should fix the frogged people fake counter||

last hemlock
#

omg, over 77M other people who have been frogged!

lucid belfry
#

crazy how it happens

lucid belfry
inner frost
lucid belfry
#

the pr just adds infra for internationalisation

inner frost
#

o ok

lucid belfry
#

apparently this is compatible with extractor

echo bronze
#

Is this available as a separate component?

#

Could be used to enhance markdown

#

So that users don’t have to use styles and center

lucid belfry
lucid belfry
#

fixed the PR, cannot test on windows since I don't want to touch yarn on my system anymore

#

old yarn has trouble understanding npm aliases, so it was writing multiple modules over one another and caused issues with cjs/mjs incompatibility

lucid belfry
#

TODO for later: see if knossos can switched to bundler mod resolution once nuxt is properly updated.

#

(only partially related to the whole i18n shenanigans and doesn't actively cause issues right now)

arctic pulsar
#

@lucid belfry your pr is approved, can you just fix the conflict in the lockfile

lucid belfry
#

ouch, after re-applying lock file it pulls the newer version of formatjs libraries which had breaking changes marked as minors again .-.

#

gotta fix that first

arctic pulsar
lucid belfry
#

do you mean the translations that are currently on crowdin? if so, no, cause the format is different and also it doesn't make much sense since many things changed since rewrite and rewiring existing strings would be somewhat difficult, whereas creating new strings is much easier now as there's an extractor — you just write defineMessages in code and then run pnpm intl:extract and it makes en-US.json for you

lucid belfry
last hemlock
#

your new PRs broke your translation PR, it seems šŸ˜›

lucid belfry
#

wait, the bundler one?

last hemlock
#

yeah

#

idk how else we would be getting ts type errors

lucid belfry
#

yeah, it would break because I used the hack to get typescript to understand these modules structures

#

oh I see both are merged

#

okay I'll rebase

last hemlock
#

I pushed a merge commit and a couple bs commits to your branch

#

so idk if that is going to mess you up

#

it's all going to be squash-committed anyway so it doesn't matter an awful lot

lucid belfry
stable lark
#

šŸ„³šŸ‘ congrats braw, it's finally here! you have put in an insane amount of work into i18n, and the base is finally here!

#

up next is the language selector, I assume :)

lucid belfry
#

yeah, and v5 of VIntl

#

with lots of useful semi-stateful components like FormattedDate, FormattedMessage, etc, and then useMessages composable

last hemlock
#

and have a bit of dough out of my pocket in return :)

lucid belfry
#

!! :O tysm!!

swift raft
#

did you ever resolve that one situation

#

I imagine so right?

lucid belfry
#

mhm :NODDERS:

arctic pulsar
#

@lucid belfry what's left for il8n? is it just a language selector and localizing the pages?

last hemlock
#

you do realize it's i18n, not il8n, right?

arctic pulsar
#

oops

lucid belfry
#

for the most part it works

final tangle
#

I think it might be better if you didn't see the actual picker when that's visible. Blur has known to cause performances problems, and on some older system might not work at all.
Another option would be to include the "Browser language as one of the language cards and have it as the first one

lucid belfry
#

it used to be brighter white that it's barely visible even without blur and also it respects advanced rendering setting

final tangle
#

Does it look properly greyed out on dark theme (without blur)? My only other concern is that this style isn't really used anywhere else and feels a bit out of place

lucid belfry
#

re: #api-development message
I think nuxt has changed how options are added by modules and I somehow missed that

#

because I checked and yeah, typescript sees anything else provided by the module except for the options

#

maintaining nuxt modules is one kind of a hell

#

yeah, see

last hemlock
#

sorry, not enough jpeg, could you jpeg it up some more?

lucid belfry
#

there are no serious jpeg artefacts, it's just pixelated noisy background, it's not due to compression

lucid belfry
#

Indeed they have changed how options are added

#

they used to just grab the options by doing default extends NuxtModule<infer Options> ? Options : Record<string, any>

#

but I think the newer approach is more resilent to version mismatches

lucid belfry
#

me: I'm going to update it in knossos
also me: oh right my codespace is ded

lucid belfry
lucid belfry
#

what if :grab: discord / revolt language page

swift raft
#

looks good to me lol

lucid belfry
#

are you kidding me

#

chromium just ignores languageDisplay of Intl.DisplayNames API

#

or is it edge whaat

#

welp I guess we're translating language names manually

#

alternatively we can use default style but idk

#

I feel like American English looks nicer than English (United States) ?

#

also for other languages it will use lowercase

arctic pulsar
lucid belfry
#

nvm it also doesn't support languageDisplay

#

yeah I think translating language names ourselves would be the best approach

#

Input
new Intl.DisplayNames('uk', { type: 'language' }).of('en')`
Output
'Š°Š½Š³Š»Ń–Š¹ŃŃŒŠŗŠ°'

#

it supposed to return names how they'd be written in the middle of the sentence

#

which is not what we really want

dense oasis
#

ah that's a property

final tangle
lucid belfry
#

idk where to place the invite to contribute

#

looks out of place

lucid belfry
#

this works ig?

stable lark
#

I would prefer "English (United States)" - if for whatever reason I need to change the language back to english, I'm going to be looking for "English" not "American English"

swift raft
#

yeah agreed

swift raft
lucid belfry
lucid belfry
swift raft
#

nice!

dense oasis
#

ā¤ļø

lucid belfry
lucid belfry
#

I am doing some cursed stuff because web dev is stupid šŸ‘

#

basically regular input[type=radio] elements only focus on currently selected item and change upon pressing arrow up and down

#

which means that the user that relies on a keyboard will change language on every freakish up/down press

#

which is absolutely terrible

#

I am debating whether to continue with cursed fake radios, fake pressed buttons or making it so that radios don't immediately apply (requiring confirmation) unless clicked

#

web is absolutely cursed

#

I think fake pressed buttons makes a lot more sense and also won't require to implement arrow keys handling

#

I am not sure the screen reader users will appreciate that but alas

#

I don't think I am capable to implement something like discord's focus magic

lucid belfry
#

I just found out that I have vercel enabled for my knossos clone

stable lark
#

are radio buttons used anywhere else on knossos?

#

I feel like they should be green

lucid belfry
#

brand green didn't look good :(

stable lark
#

I don't think it's awful

lucid belfry
#

ehhh

stable lark
#

I think it's just a little hard to tell what's active in the current design

#

and it would be worse with dozens of options

#

maybe just a brighter white would be better

#

with #fff

lucid belfry
#

I think the whole row needs a highlight but I haven't found the darker colours and I am not sure how modrinth approaches adding new colours to the palette

swift raft
#

so I'll probably update that to this style

swift raft
#

hey @lucid belfry so I'm looking at the i18n impl since I wanna start using it for future features, in the frog example it looks like each string is duplicated, why is that

lucid belfry
#

wdym

swift raft
#

like it's in index.json and in the frog.vue file

#

is the index.json auto generated or something

dense oasis
#

afaik it's just automatically grabbed from the vue files, just like gettext does with C

lucid belfry
dense oasis
#

||wait, is the majority of vintl made by you?||

lucid belfry
#

all of it

dense oasis
#

did you just make this for modrinth

lucid belfry
#

mhm

#

if you remember there was a lot of spaghetti on first iteration and I just moved it all to a formal module

dense oasis
#

i am concerned

stable lark
#

yeah braw is a madman but it works and its awesome

dense oasis
#

actually, I'm a bit misinformed: why aren't you doing it like gettext with _("C locale message")?

stable lark
lucid belfry
swift raft
stable lark
#

anyway, modrinth contrib docs probably should be modified to provide guidance on how to do i18n correctly

#

but first there probably needs to be i18n actually being used in other places than /frog lol

lucid belfry
# swift raft running this I get an error on a random component ```Error: components/ui/threa...
GitHub

Our Vue-based frontend with server-side rendering and caching for great user experience, speed, and compatibility. - knossos/components/ui/thread/ThreadSummary.vue at 21095a5348c0c77c3b6585b389ce0c...

swift raft
#

idk doesn't make sense to me

lucid belfry
#

oh it's because of of in loop

#

change it to in it should work the same, but will fix that error

swift raft
#

ah

#

very helpful error okhappy

#

ty for the help

lucid belfry
#

in case you wonder why it says like first line is because they iterate all template expressions via typescript parser and set the file name to vue file

swift raft
#

got intellij setup to run intl:export when I save a vue file

#

seems to work well, so that's cool

#

don't have to run it manually

#

it's just a little slow but not a big deal

#

takes like 6 seconds or so

stable lark
#

I'm wondering, at this point would i18nification PRs be accepted?

#

they need to be done at some point and I can't imagine it'd be very hard

swift raft
#

I'd wait for threads-and-more to be merged

#

but after that, yeah I don't see why not

#

would be a big help

lucid belfry
#

just don't be me and don't translate everything at once šŸ™‚

stable lark
#

threads-and-more will be great, hope it gets merged soon

stable lark
#

but I won't do it unless it's wanted, obviously

lucid belfry
#

I have a few DX changes in mind

swift raft
#

I dunno about typescript but we definitely want to move everything to composition

#

tbh there's not a whole lot that's not composition already

stable lark
#

I think typescript is nice for maintainability, especially for something like knossos which has no internal documentation and gets outside contributions

stable lark
lucid belfry
#

oh it's more just like refactors and cleanups here and there

stable lark
#

ah, yeah that definitely could be used

swift raft
#

@lucid belfry is there any good way of localizing list formatting?

#

like given [ "Fabric", "Forge", "Quilt" ] format it as "Fabric, Forge, and Quilt"

lucid belfry
#

of course

#

destructure formats from vintl and you'll have list, or use vintl.intl.formatList, they're the same thing essentially, except destructuring formats is much safer in reactivity terms (it's a reactive object that updates, whereas intl only shallowly reactively updated, so cannot be destructured)

swift raft
#

ah nice!

#

thanks

stable lark
#

will omorphia integrate with i18n/vintl easily?

#

I know there's not much text inside omorphia but there is some like the environment indicator

swift raft
#

good question, not sure how that will work lol

#

I think the easiest thing is to make omorphia not handle text

lucid belfry
lucid belfry
arctic pulsar
lucid belfry
#

I wanted to eventually, but I don't think I could handle much publicity right now, there quite a few things I wanted to do first in calm pace laugh

last hemlock
#

@lucid belfry any chance that crowdin can be updated with the language files we have now? in a recent team meeting we basically came to the agreement that all future PRs should be done with i18n in mind

lucid belfry
#

you can connect the crowdin integration or setup a manual workflow using their action

instruction in the PR that started it all should still be correct
https://github.com/modrinth/knossos/pull/738#merge-and-integration

the action, if you're interested in having more control:
https://github.com/marketplace/actions/crowdin-action
e.g. with action you can set it up so that whereas any PR gets labeled with say *push-i18n or gets a push and has that label, you'd upload the updated locale files on crowdin under a feature branch, which would allow you to make it possible for translators to translate feature branches before they're even merged. I'm not sure how to download translations for these branches, though, I think there's pull_request_target for that, so that if PR target gets labeled *pull-i18n, you can pull translations, create a commit, and remove the label, and then you can merge it with new translations. this all is not really necessary, though, since master is staging anyway it alone will work just fine

#

I'd go with crowdin integration for now and explored the action later, although it's also not necessary, just allows more control over when and how translation pull requests are created

last hemlock
#

is it safe to delete the translations repo and associated files on crowdin or will that mess up tm?

lucid belfry
#

you can disconnect that repo in crowdin integrations and then archive it maybe for reference, although crowdin should preserve the translation memory

last hemlock
#

so can I delete the Knossos frontend (Outdated) source?

lucid belfry
#

hm it should've removed itself after integration disconnect, but maybe they changed that after our previous accident tiny_pumpkin

#

(that time when we changed the key or sum? and it reconnected the integration and all files and translations were effing gone)

languid crest
#

will we be able to select the language, bc I prefer to use sites in english, but my secondary machine uses my local language

lucid belfry
#

of course

languid crest
#

Nice!

lyric dove
#

i wonder how they did turkish

inner frost
pure breach
#

does that mean that we need to retranslate all the stuff again or just translate the new strings?

lucid belfry
#

hey this channel is meant for development conversation, for talking about translation process itself use #1021064334207627375

lucid belfry
lucid belfry
#

very very neat

arctic pulsar
#

@lucid belfry what would the ideal structure look like to you for error messages to be localizable to the frontend?

#

imo it seems really tough to do on the rust end of things and i think the better solution is just better form validation on the frontend (which is most errors)

lucid belfry
#

most APIs I saw either provide a code or both the code and english error message

lucid belfry
#

wondering whether onError should be a part of the parserOptions getter / object

icuMessages({
  format: 'crowdin',
  parserOptions() {
    return {
      ...this.getDefaultOptions(),
      onError({ error, message, moduleId, useBuiltinStrategy }) {
        console.error(`failed to parse message "${message}" in "${moduleId}": ${error}`)
        return useBuiltinStrategy('message-as-literal')
      },
    }
  },
}),

or plugin options instead

icuMessages({
  format: 'crowdin',
  onParseError({ error, message, moduleId, useBuiltinStrategy }) {
    console.error(`failed to parse message "${message}" in "${moduleId}": ${error}`)
    return useBuiltinStrategy('message-as-literal')
  },
}),
last hemlock
#

hmm yes 60 minutes ago

#

I think there's a term for that, can't remember what it is tho /lh /j

inner frost
#

quad-quarter minutes

lucid belfry
#

yea mysterious already pointed that out

lucid belfry
#

why would you use banker's rounding method for your relative time, I don't know, but I added that just in case

lucid belfry
#

yaassss

lucid belfry
# lucid belfry yea mysterious already pointed that out

https://github.com/vintl-dev/how-ago/releases/tag/v3.0.0 šŸ™Œ

  • several rounding modes for all your needs: "ceil", "floor", "expand", "trunc", "halfCeil", "halfFloor", "halfExpand", "halfTrunc", "halfEven". explanations are available in readme
  • trunc rounding mode is used by default, which means all durations are rounded towards 0. for example, 1.8 years will be rounded to 1 year now, compared to 2 years previously
  • new unitRounding option allows to control whether the rounding of calculated duration should be rounded to the higher unit if possible. for example, when set to false, and with rounding mode set to halfExpand, duration such as 59.8 minutes will return ā€˜in 60 minutes’, rather than ā€˜in 1 hour’ . (in case you are nostalgic for the terrible old behaviour, I guess)
GitHub

3.0.0 (2023-10-13)
Features

enable "unitRounding" by default (c56f6fb)
make "trunc" the default rounding mode (803439b)

BREAKING CHANGES

"trunc" logic is very diffe...

lyric dove
#

im sorry if its rude to ask but whats the status on this?

#

i keep telling people (in my country) about modrinth and they dont pick it up or some cant use it because theyre not that great at english

#

wait a second
i just realized almost all content is english and i dont think they can be translateable

#

šŸ¤” would it be a good idea if projects could have additional markdown for other languages?

lucid belfry
#

there's already discussion for that on github

#

I suggested idea of details with lang attribute as a temporary workaround but it was rejected

#

so even if we localise the site you gotta wait until this idea is implemented

#

or you can use details tags but they will not be open by default

lucid belfry
#

though I actually should be spending blocked time working on VIntl but every time I look at the github project for it I go woof oh maybe later

#

I never knew backlogs can be so scary

lyric dove
#

lmao, goodluck thrn

lucid belfry
#

I think nuxt theme scrapped docus, it's not even working out of the box anymore

#

oh well I guess vitepress it is although I don't vitepress that much (mainly because there no auto-discovery feature and it looks way too simple)

#

though one important thing is that using a nuxt-powered doc site allowed to use vintl for nuxt in there .-.

#

essentially acting as a playground

lucid belfry
tribal linden
#

I was thinking, how are we going to translate the legal pages?

#

Is it preferable/possible to use markdown? Or is there another way?

last hemlock
#

It's certainly possible to do markdown

tribal linden
#

@lucid belfry ?

last hemlock
#

However, we cannot make translations legally-binding unless they are written by legal experts

lucid belfry
#

currently those pages are components by themselves

arctic pulsar
#

don't translate the legal files

#

but it's fine to translate the titles and the sidebar

tribal linden
#

As you want, but, the migration to nuxt content still be useful for you ?

lucid belfry
#

most freaking tragic story imaginable

#

screw it I'm implementing URL parameters in vintl unplugin (ļ¾‰ą²„ē›Šą²„ļ¼‰ļ¾‰å½”ā”»ā”ā”»

last hemlock
lucid belfry
lucid belfry
#

I guess that's good enough

#

I think compact one looks a lot better

#

but gosh am I happy to get rid of zod

#

one of the huge benefits for consumers is that all options are now typed

#

for developers the benefit is their tsserver not dying due to heap errors