Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Data Language User-selectable #52

Closed
Tracked by #49
qjzcj2008 opened this issue Oct 17, 2022 · 4 comments
Closed
Tracked by #49

Make Data Language User-selectable #52

qjzcj2008 opened this issue Oct 17, 2022 · 4 comments

Comments

@qjzcj2008
Copy link
Contributor

I found that the medal you got, the title on the banner, and some other information the splatnet3 provided are only in plain-text strings form rather than ids. And I looked up the databases from datamining, I don’t think it’s easy to do the i18n process on Stat.ink side for data display.

I think maybe just letting users choose what language their data they want to store and display on Stat.ink would be a better and easier way for everyone. Also, I noticed that the information (like abilities, gear name) of the gears you wear are not provided with their ids, just plain-text strings. Not sure will Stat.ink add support to log and analysis gear as they did in Splatoon2 battle log, I think maybe we could use the URLs of gear pics and ability iconsto extract their hashed filenames as the ids to recognize the gears and the abilities when Stat.ink adds gear log and analysis function. I don’t know if I should at the maintenance of Stat.ink here to discuss the questions above.

In current version, s3s uses the language which returned back from Nintendo API users/me port to fetch data from splatnet3. In a previous issue, I saw some discussions about this, but that time we didn’t come up with a conclusion, only using a modification s3s as a temp method. But after doing this modification, it becomes kind of inconvenient when I need to update my s3s, cuz I must revert the change I made to the codes before updates. I did some tests and maybe can explain the language and country returned from Nintendo API. Here’s my assumption, the language is relevant to which language you use on the Nintendo Account web page, not relevant to your settings on your console. And the country seems to be the "Country/region of residence" setting listed on your Nintendo Account web page. And the Accept-Language header which leads you to the NSO splatnet3 page in your preferred language is depending on the device language setting which you use NSO app on.

I looked into imink API Documentation and found that language and country will be used in generating session token and bulletToken. And the Nintendo Account web page supported language list can't cover all languages that Splatoon 3 and SplatNet 3 supported. So maybe we need to add a new configuration key to store what language users prefer to use and use it to set Accept-Language header in bulletToken generation and GraphQL request in splatnet3.

@spacemeowx2
Copy link

Hi, I have the same problem.

I tried to rewrite s3s in TypeScript because I'm not very good in Python. It's a redesign, so it's better in terms of architecture and performance.

It's a bit rude but I'd like to promote my project here: https://github.com/spacemeowx2/s3si.ts

@frozenpandaman
Copy link
Owner

I think maybe just letting users choose what language their data they want to store and display on Stat.ink would be a better and easier way for everyone.

@qjzcj2008 That was the intended goal of the "acc_loc" key in config.txt being having the format of locale|lang, so that users could edit it as they see fit, but it would initially be pulled from your Nintendo Account. Turns out it doesn't exactly work like that and the locale is just set to en-US for everyone, for some reason…? Or maybe like you said it's tied to the account you use to browse their site. See #6 for more discussion – but I agree that we'll want to revisit that and change some things, then.

As you suggest here, it seems returning to the s2s model would be best, where we prompt people for their USER_LANG manually on first run/config.txt generation – so it's no longer something that gets set automatically. That language will then be used in requests, which will get medal & title data correctly and solve this issue.

cc @paul-sama

@frozenpandaman
Copy link
Owner

@spacemeowx2 I'd encourage you to still contribute any new features, ideas, etc. here (even if you can't develop them yourself as you're not familiar with Python, just like I'm not with TS – which is fine) so we can benefit from this too. And if it's just a direct rewrite of this codebase, parity would be nice to have, or at least for them to not wildly diverge in the future!

@frozenpandaman frozenpandaman mentioned this issue Oct 27, 2022
11 tasks
@frozenpandaman
Copy link
Owner

Should be all working now, but please test this out when you can @qjzcj2008 @paul-sama @spacemeowx2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants