Can support other languages?

[aShen-onei]

Hello! Guys,this project is awesome! I like this project so much and have used it on my personal project.

But i have some question, I am a chinese, when i use the api, I have to translate the res to the simplified chinese and the traditional chinese, so I want this project can support other languages like chinese.I want to set a PR but I'm sorry that I'm not goot at PHP 😭,I can translate this project to simplified chinese and the traditional chinese with my friends. I believe that if this project can have a globalization document, it will be more and more people use it! ( I can learn PHP!

[LartTyler]

This is definitely something that I'd like to support in the future. I'm going to add it to the backlog, with the goal of focusing on international support as soon as I have the time to devote to it. I'll post status updates to this thread, and will let you know when it's ready!

[aShen-onei]

yeah,it sounds cool, if u need I translate,I will do my best! I can translate it to the simplified chinese and traditional chinese.

[mingjunlu]

I can help with traditional Chinese translation as well 🙂

[LartTyler]

I'd like to start working on planning this feature out in the near future. I'm not super familiar with the actual practice of localizing / translating an application, but I'd like to lay out what I'm currently thinking so I can get some feedback.

The cleanest way to do this, in my opinion, would be to add an optional language tag prefix to every route in the API, e.g. /zh-CN/weapons/1, which would use "en-US" as the default locale if it's omitted (to preserve backwards compatibility). In the database, string columns would be split out into their own table (e.g. weapons and weapon_strings), which would be indexed by the primary key from the main table weapons and the language tag that the strings belong to.

In cases where the region part of the language tag (the part after the dash, e.g. "-CN") is omitted, the system can try to fall back on the language part of the tag. That way, different tags that share strings (i.e. "en-US" and "en-GB") can store their data in the same columns, instead of having two rows with the same content, one for each tag.

Based on the analytics I have for API usage, I think the following regions should be supported initially.

Language	Tags
English	en
German	de
French	fr
Chinese	zh-CN, zh-TW, zh-HK

All of the languages listed above have a significant amount of API usage over the last 7 days, which I believe makes them good candidates for initial support. Obviously, I'll need to find people that speak the language to actually get the translation added to the API. To anyone following this project, if you'd like to see your locale added to that list, please let me know!

@aShen-onei @mingjunlu I don't know enough about simplified vs. traditional Chinese to know if all 3 of those language tags need to be supported. Going by what I can find online, it sounds like both "zh-TW" and "zh-HK" are for traditional Chinese. If that's the case, it would probably be enough to make "zh" traditional Chinese, with "zh-CN" mapping to simplified. Please let me know if that's accurate so I can decide how best to support translations for Chinese.

[aShen-onei]

In my opinion, simplified chinese are more used in Mainland China, traditional chinese are used both of Mainland China and HK or TW China, but on PC, Mainland China player base is large, so I think more player would like to use simplified chinese, it's better to use "zh" or "zh-CN"for simplified chinese as defalut, "zh-TW" as traditional chinese, “zh-HK” is rarely used as traditional chinese tag,( e.g https://developer.mozilla.org/zh-TW/docs/Web/JavaScript) from my experience 😂,

[mingjunlu]

Going by what I can find online, it sounds like both "zh-TW" and "zh-HK" are for traditional Chinese.

Correct! Traditional Chinese characters are used in both Hong Kong and Taiwan. There are some area-specific words, perhaps that's the reason why the [language-area] format exists for. Not really sure though. Anyways, I don't think that you have to support all 3 language tags at the current stage, since the Traditional Chinese characters used in Hong Kong and Taiwan are basically the same. Distinguishing between Simplified Chinese and Traditional Chinese is good enough.

If that's the case, it would probably be enough to make "zh" traditional Chinese, with "zh-CN" mapping to simplified. Please let me know if that's accurate so I can decide how best to support translations for Chinese.

Given that many web services now refer "zh" to Simplified Chinese, using "zh" to represent Traditional Chinese may cause some confusion. Therefore, I would go for "zh-CN" and "zh-TW". Or if you want to be more accurate, you can use "zh-Hans" for Simplified Chinese, and "zh-Hant" for Traditional Chinese (following IETF BCP 47 - Tags for Identifying Languages).

P.S.
It seems that "zh-HK" is relatively less used, like @aShen-onei says. Still, the official MHW website uses "hk" to represent Traditional Chinese for unknown reasons 👀

[LartTyler]

If "zh" is usually used to refer to simplified Chinese, then I'm happy making that the fallback instead. It also sounds like "zh-Hans" and "zh-Hant" are what I was looking for, as opposed to the region codes. Thanks for linking that, it was incredibly helpful. Here's the revised list.

Language	Script	Tag
English	—	en
French	—	fr
German	—	de
Chinese	Traditional	zh-Hant
	Simplified	zh, zh-Hans

[LartTyler]

Would it also be a good idea to include translations for enumerated values, like weapon.type or armor.type? I'm leaning towards no, since they're a defined list of values, and I don't believe it would be unreasonable to have application developers handle rendering the values to their users in the appropriate language. What do you guys think?

[aShen-onei]

I think....it's not a good idea (￣y▽￣)╭ Ohohoho.....always feel a bit out of step😄, guy u can use a url type like:
https://mhw-db.com/zh-Hans/ailments
https://mhw-db.com/zh-Hans/armor/sets/<id> or other Apis.
Also u use a query data:
https://mhw-db.com/ailments?lang=zh-Hans
https://mhw-db.com/armor/sets/<id>?lang=zh-Hans
Oh! I remember a Api website that I have used.Do u guys play warframe? The game also have a Api project,it's also a good example~

[mingjunlu]

I'm not familiar with localization, but it seems a little bit cumbersome to translate values like weapon.type and armor.type.

[LartTyler]

Localization support has been added with v1.18.0! For those that were interested in helping with translations, the contribution site will now have a dropdown in the top right that will allow you to select which language you'd like to use to access the API. Since missing strings will show up as blanks in the contribution site, I'd suggest navigating the site in English, like normal, opening up the editor for something you'd like to update the strings for, then changing to the language you'd like to update.

Please let me know if you have any questions or issues with the new system. I tested it pretty thoroughly on my machine before pushing it out, but I'll be really surprised if everything works 100% correctly haha. I'll be keeping an eye on this thread, but you can also reach me (probably faster) via the project's new Discord server.

[mingjunlu]

@LartTyler Thanks for your great work!

Since missing strings will show up as blanks in the contribution site, I'd suggest navigating the site in English, like normal, opening up the editor for something you'd like to update the strings for, then changing to the language you'd like to update.

When editing an item (e.g., an armor, a skill, etc.), is it possible to show the original text in English? Like, is it possible to make the original text in English as the placeholder? Without a reference to the original text, It would be really painful to work on the translation. Jumping back and forth or opening multiple pages at the same time significantly slows me down 😭

[LartTyler]

That... is a very good point. I honestly hadn't really considered that when I was putting things together. Sorry about that.

As far as the defaulting to English for missing values, do you think that makes sense only in the context of the contrib site? Or do you think that behavior should also be present in the API itself, in that string fields without values fall back on their English counterpart?

[mingjunlu]

As far as the defaulting to English for missing values, do you think that makes sense only in the context of the contrib site? Or do you think that behavior should also be present in the API itself, in that string fields without values fall back on their English counterpart?

In my humble opinion, the second approach (returning untranslated string fields) might be slightly friendlier to users. If I were a newcomer and had neither read the docs carefully nor followed the issues before, I would not know that the translation is still in progress. As a result, once I see the null values returned from the API, I might think that the API is not functioning at all. In contrast, if untranslated string fields are returned in English, it implies that the translation is incomplete, but the other parts of the API are still working.

[LartTyler]

Which is basically what happened in #157. That's what I was leaning towards as well, but I wanted a second opinion before jumping straight to that.

To keep things simple on the backend, and to avoid having to load both translations for every request in case any field is null, I think what I'll do is default to English if there are no strings for the selected language. So for things that haven't been translated at all, it'll return the English fallback, but as soon as any strings on an object are translated, it'll return all strings in that language, even if not every field has been translated. That way, in the worst case scenario, it appears that data is simply incomplete (which it is, in that case), instead of broken altogether.