search

processing / p5.js-website-legacy

Archived p5.js website 2015-2024
http://archive.p5js.org
MIT License
240 stars 483 forks source link

Return type is not displayed in translation of references. #617

Closed ayushjainrksh closed 4 years ago

ayushjainrksh commented 4 years ago

Actual Behaviour p5issue8

Expected Behaviour p5issue9

Would you like to work on the issue? Yes

limzykenneth commented 4 years ago

The fix is causing the untranslated type to show up in the translated reference, even in cases when the type has been translated. The issue is not The original value is not retained by rather the translation did not include the type in some cases (but not all).

ayushjainrksh commented 4 years ago

@limzykenneth The reason why I preferred displaying the return type in English is they can be of any type. For example, p5.Color is an object. Shouldn't it be displayed in English? Also trivial return types such as Number and String can also be displayed in English as they are specific to the programming. It would be difficult for user to read the specific return types in their native language and then code in English. What do you suggest?

limzykenneth commented 4 years ago

For something like p5.Color it is a specialized type and it made sense for it to be as it is since translating it wouldn't be helpful. For generic types like Number and String these are basic programming terms that can be found in almost all programming languages and as a result is also commonly translated in reference materials for various programming languages in various languages. I see them as in the same class as terms like function, variables, class, array, etc, some of them are keywords in Javascript but if it is not used in code, we translate them all.

It also isn't a very common occurence that you need to (or should) reference the generic types directly.

In the end, the system is setup so that the translator can make the decision about whether to translate a term or not, if the translator deemed it not necessary to translate the term because of existing materials in their language or other reasons, keeping the return type translation mechanism as it is provides the most flexibility.

ayushjainrksh commented 4 years ago

Well that does make sense. The only problem is we need to update the translations to add data types to the translation in the reference json. Because, currently I can see a lot of them do not translate the return types. For example in pow function, the Spanish translation does not display the return type. I will update all the Hindi references to support the changes.