Resources: Improvements to the lang.[language] structure

[JLGarber]

As noted on #1207 , the current setup of having a separate language file for each supported language is rather cumbersome and prone to forgetfulness from maintainers. My typical reaction to these sorts of situations is "let's build around it rather than restructuring":

That being said, a thing we could do that would require less restructuring is to place a "master elements object" into the EN language file. Something like:

masterObject: {
  actionsToTranslate: {
    Action1: 'ID1',
    Action2: 'ID2',
    // ETC
  },
  statusesToTranslate: {
    Status1: 'ID1',
    Status2: 'ID2',
    // ETC
  },
  // ETC
}

From here we could just update a file in one place, and then run a script to pull in translations and update the relevant language files.

A more expansive solution that also doesn't make structural changes would be a script to scan trigger files for k[whatever] elements, grabbing those translations from the appropriate resource sites, and automagically dropping those into the relevant translation objects in each [language].js file.

I'm not familiar enough with the internals of the translation engine to speculate about how we might change that if we're going to do something structural, unfortunately. When I get a little more time this summer I would be happy to look into an implementation if we come up with something as a group.

[quisquous]

Yeah, sorry that the language system is so half-baked. I wasn't quite sure what I needed when I wrote this, and then raidboss turned into something different and diverged from oopsy and jobs. It just hasn't been the highest priority (and probably isn't, even now, but it's causing bugs, so here we are.)

I think my reaction to these sorts of problems is to identify what all the issues are, see if there's something that can solve all/most of them, and see what steps towards that would look like.

Here's what I see the problems being:

• translations spread across multiple files are error prone
• not everything in cactbot uses these consistently (raidboss translates effects inline whereas oopsy leans on lang.js to translate effects)
• some things in language files aren't even translated (e.g. zone names)
• there's regexes in language files and in regexes.js
• initialization is kind of awkward (you have to do some init before using gLang, so can't use it directly in an oopsy line)
• oopsy originally used these a lot, but then got some helper functions that removed the need for it

I think the actions should probably just go away. I think I had thought that maybe raidboss would use them, but actions aren't really duplicated, and so any actions that jobs is using should just move into jobs. They're not really "translations" and in that sense maybe don't belong in the language files. Especially with raidboss transitioned to just ids, then maybe oopsy should do that in all cases too. The newer helpers in oopsy for damageWarn just use ids, and they're a lot easier to use.

I think effect-wise, I was wondering if maybe some auto-generated file like resources/hunt.js with a script would be better. It seems kind of silly to have to make people automatically translate these. There might be some issues where the ability name is duplicated across a number of ids. I'd have to see if the translations for those are identical as well. But, we could have some static mapping of english name -> {translations}. We could also have a map of effect id -> english name.

If that happens, then what's left in the language files?

• zone names: maybe should move to their own file? this also hasn't been translated either? maybe we just punt on this until we can use zone ids everywhere
• countdown/zone seal/etc regexes: right now, regexes.js assumes that it is operating on translated strings and doesn't know about languages, maybe it could? would it be weird to have a Regexes.countdown({lang: 'de'}) style helper? Or maybe they could get grouped in another file?

This is all a bit wishy washy, but I think what I'm getting at is that I like the way that raidboss just explicitly handles translations and passes around response objects with multiple translations in them to select from. I wonder if it'd be better to just drop the lang.js and friends files entirely and move towards data structures and functions that require explicitly passing in the current language. This would at least make everything more consistent.

[JLGarber]

On effect translations, it's tough with multiple possibilities. In the past, I would just use the effect that was correct for that specific piece of content I was working on, wherever I came across it. (Which, yes, would break if other content uses ID2 where I used ID1.)

You're right that we should move to using effect IDs everywhere so as to be explicit. This wouldn't necessarily be a problem anyway, since we're already looking up the effect ID to find the correct CN/KO translation in these situations.

I agree that your last paragraph is probably what we should be working toward. That works well enough for raidboss, and the duplication of effort that it incurs really isn't worth considering. (Plus, as I'm seeing from my work on normal modes, it can save a ton of time for normal vs EX/Savage content.)

[JLGarber]

Looking at this again, I think we're most of the way there in terms of removing our dependence on lang. Now that oopsy has NetRegex support, there's effectively no need for the gLang helpers there, and you're just about finished with removing the need for zone names. That just leaves the countdown/zone seal stuff, and I think you're right that that should turn into a helper of some sort as well. I think it should probably live on its own rather than being a (Net)Regex subset?

[quisquous]

Also upon reflection, I think resources/content_type.js and resources/zone_info.js should be enough to get rid of the baked in zone names, as you can differentiate the content type by its zone id once #1037 is complete.