translations for new error messages

[KotlinIsland]

For new errors such as reportAny etc

Currently they fall back to en-us

[sena-nana]

Hello, I am a CJK language user and I recently switched to this program and have been pleasantly surprised Regarding the error message, maybe it's pyright's localization ability that it shows up in the correct language.It looks just like pylance. Nothing out of the ordinary. I'm not sure if this is the information the author is looking for, I'll help if something else is needed

[DetachHead]

@sena-nana thanks for offering to help! this issue is specifically referring to some additional error messages i added to package.nls.en-us.json for the reportAny rule, but didn't bother adding to any of the other language files. if you enable that rule and create an Any expression, what message do you see?

# pyproject.toml
[tool.basedpyright]
reportAny = true

from typing import Any

foo: Any = 1

[sena-nana]

@DetachHead In the Chinese language pack environment, it is displayed in English

[DetachHead]

thanks! feel free to contribute translations for those errors if you want

[sena-nana]

Glad I could help. I'll try to do the chinese translation, but since I'm quite busy at work, it'll take me a while to get this done and make sure it's correct. Incidentally, some of the Chinese translations of pylance are problematic, do you have any plans to fix the translation of pylance?

[DetachHead]

Glad I could help. I'll try to do the chinese translation, but since I'm quite busy at work, it'll take me a while to get this done and make sure it's correct.

all good, no pressure

Incidentally, some of the Chinese translations of pylance are problematic, do you have any plans to fix the translation of pylance?

depends. could you give an example? since pylance is closed source it will probably require re-implementing the feature completely.

[sena-nana]

depends. could you give an example? since pylance is closed source it will probably require re-implementing the feature completely.

Since I have disabled pylance, those translations are still there. I'm guessing the localization is probably done in the language pack extension and not in the pylance extension. Regarding translation errors in pylance, here is an example of one of them

 def example(a=1, b):

It throws the error "非默认参数遵循默认参数"，It is a direct translation of ”non-default argument follows default argument“。Here follow is translated as "遵循", which doesn't have the meaning of spatially placing something behind something,So it makes it impossible for developers to understand what's going on. The correct translation is "非默认参数跟在非默认参数之后",which describes the spatial rather than conceptual non-default argument following the default argument. (Of course this is still not the most linguistically correct translation, just a correction of the wording)

[DetachHead]

here's where that string is coming from https://github.com/DetachHead/basedpyright/blob/041f1bf562728fcddf36c2de7c40339c7aee06ab/packages/pyright-internal/src/localization/package.nls.zh-cn.json#L322

[sena-nana]

here's where that string is coming from

https://github.com/DetachHead/basedpyright/blob/041f1bf562728fcddf36c2de7c40339c7aee06ab/packages/pyright-internal/src/localization/package.nls.zh-cn.json#L322

Indeed here, it looks like the localization was done in pyright and was able to be modified in fork？

[sena-nana]

I've done a preliminary translation with reference to pylance's wording, however in my discussions with other programmers, they've given me feedback that pylance style translations make it obscure, and that translating it according to the language convention makes the style inconsistent. I guess it's up to the maintainers to decide what to do.

[KotlinIsland]

@sena-nana In what way does the style become inconsistent, could you provide an example?

[sena-nana]

@sena-nana In what way does the style become inconsistent, could you provide an example?

For example, pylance translates "the type is Any" as "类型 (the type) 任意 (any)", which means "the type is arbitrary". This is clearly a deviation from the original meaning.I think a more accurate translation would be to treat Any as a specific type and translate it as "类型 (the type)为 (is) Any"

[KotlinIsland]

That sounds very good, the current translation is trash. If this is demonstrating the deviation of consistency you mentioned, then I think it's a based deviation for the better and other error messages should be updated to match.

If you could put together a PR with your suggestions it would be greatly appreciated.

[sena-nana]

That sounds very good, the current translation is trash. If this is demonstrating the deviation of consistency you mentioned, then I think it's a based deviation for the better and other error messages should be updated to match.

If you could put together a PR with your suggestions it would be greatly appreciated.

Okay, I'll organize it and evaluate other types of translation errors as well. I'll put together a markdown for stating which words I've changed, and give a reason for doing so, so that subsequent maintainers will know why I did it, and if there are errors they can be easily fixed.

[NCBM]

Hello, I am one of the translators of Chinese (Simplified) with @sena-nana . I just realize a problem - how to solve the conflicts of translations among basedpyright, pyright (pylance) and new translations from contribution, since these language files tend to be modified in a mess?

[NCBM]

For avoiding merge conflicts, I have an idea: keep original files unchanged, and use new files to override. Looking into packages/pyright-internal/src/localization/, there are package.nls.<language>.json and localize.ts. Since localize.ts simply loads these json files and processes these text, could it be possible to add new files like basedpyright.nls.<language>.json and implement overriding, in order to avoid conflicts. What about this idea?

[KotlinIsland]

The problem with switching to new files is that things could quickly get out of sync, with no indication from any tool.

The problem with using the same file is that @DetachHead (who does the merge from pyright) can't speak all these languages.

Perhaps, if we use the same file, and @DetachHead resolves conflicts, taking note of any ambiguity in the messages, reaches out to one of yourselves to assist with resolution?

[NCBM]

In my opinion, a total switching is unnecessary while new files are just patch-like things (although for chinese text it may be as large as the original); and for "out of sync", indeed this needs extra manual work, while git diff can get changes of original files. Both choices need extra manual work.

[DetachHead]

unfortunately conflicts are inevitable since there's essentially 3 different projects (pyright, basedpyright and pylance) that need to stay in sync with each other. idk what the best approach is in this case since it depends how many conflicts you're running into and how often these translations are updated upstream.

if you think the conflicts are too much of a hassle, perhaps it's worth trying to get the changes that effect upstream error messages merged upstream instead

[NCBM]

@DetachHead It is impossible to change translations from upstream. See microsoft/pyright#7441. According to this issue, localized messages are provided by microsoft's localization team and any modification will be overridden by them.

Correcting their translations is possible but very limited. The team actually provides localization for many products of microsoft, with some wrong translations. And their response is not quite active.

And, in the feedback form, "only High Priority translation issues will be fixed."

[KotlinIsland]

That's insane... Microsoft should be reduced to dust.

[KotlinIsland]

I could be wrong, but I don't think that upstream would be updating error messages very often, and would instead be adding new messages.

So I think unambiguous conflicts would be quite limited

[DetachHead]

that sucks, i guess we just have to deal with the conflicts then. i don't think having separate translation override files is a good idea because it would likely make actual conflicts in messages we've updated go undetected

[NCBM]

Then we'll work on the original file, since it is acceptable.