[Feature]: Normalized translation return object/dict about translators HOT 2 OPEN

@jbscout

Good advice.
I have also thought about similar questions, but where is the application scenario of so many outputs, and is the output a repetition of the input? Where is my maintenance focus, what is the core. My own answer is that my focus and core is on accurate and more translation services, not derivative features. I even wanted to cut is_detail_result=True at one point. It has also been proposed to output non-auto from_language, but in fact, predicting which language a piece of text is in has a specialized library to do this, with high accuracy and little difficulty, and does not require translation services to provide it. Everyone has different personal needs, and it is more important for this library to provide stable core functionality.
Thanks.

from translators.

(Also answering your comment on #140) I see your point (especially dropping is_detail_result which is useless since the output is unpredictable), but then again the language detection of other services/libraries is probably by far not as good in as the available translation services, which are most like based on deep recurrent neural networks, which do an excellent job at precisely this task. I am not sure how you extract the translated text, but if it is a hardcoded accessor adding the detected source language wouldnt be that much of a hassle, if it is there at all, but I assume that most tranlators provide it.

Some thoughs on the proposed return data:

• detectedLanguage:
  You asked for a usecase. Its obvious to my eyes that one of the major use cases of this library (especially the auto feature) will be used to provide translation services directly to users. If the language detection is distincitve enough specifying the source langauge is redundant and saves time. As a concrete example see my keyboard launcher plugin:

As you can see there is a need.

• detectedLanguage_score: Maybe as well useful if displayed to the user, but if it does not come with an array of tranlations each with a score, i dont see much gain in it. Besides I dont know if translation engines provide it at all.
• targetLanguage, originalText, translatedText, translatorUsed:
  These are redundant. The client knows what he passes to the fuction.
• rawReturnedDict (maybe, which would be the dict currently returned from translate_text() ):
  As mentioned above the structure of this dict is unpredictable and, as such, useless to the client.

Regards

from translators.