Thoughts on future version 3.0

[ZhymabekRoman]

TO-DO list for future change:

• Move to Async code base - in general, I would like sync support to remain, and nevertheless I would like to get async support, but I'm afraid it's not possible to do such work in one code base, otherwise it will be a mess or degradation of productivity. I would really hate to have a workaround solution like SQLAlchemy did, through greenlet - https://greenlet.readthedocs.io/en/latest/

• raw model attribute support

• rewrite dictionary, example and new alternative method - About the `dictionary`, `example` and `alternative` methods #62

• Fully static typing using Mypy (now working in process - WIP)

• Documentation (Done)

• Web application and API interface (server) (Done)

• AggregateTranslator

• Size limited LRU - still need to improve ([New] Size limited LRU cache #58)

• Bulk Translation support

• Build a binaries (a suggest #54)

• Improve CLI

• Formality and glossary feature to DeepL (Consider adding the formality and glossary feature to DeepL #65)

• New translate services - Promt Translate, New DeepL and Bing Translate implementation, TranslateDict (Got another translator for you. #28) and etc.

• Try to fix Google Translate V1, and full refactor (It seems to me there are too many incomprehensible things that are implemented not exactly as Google wanted lol. I think all the code can be unified using protobuf.)

[Animenosekai]

@ZhymabekRoman I never understood why people needed async support when you can achieve the same thing with threading and I'll add things to the GitHub project for the repo right when I finish class for today

[ZhymabekRoman]

I absolutely agree with your opinion, unfortunately many people think that async is faster than sync code, but in practice, i.e. under load it turns out that async is slower than sync lol - https://calpaterson.com/async-python-is-not-faster.html

And at the moment there are a lot of libraries (including web frameworks) which are only async and somehow interact with them. Probably, this idea should be put aside, if need be we'll have to develop it in a separate branch

[ZhymabekRoman]

@Animenosekai, I found a library for working with languages, it may be useful, we can fork it and refine it - github.com/rspeer/langcodes

[Animenosekai]

yup will check after school

[xitex]

Hi friends, Thank you for your work! I tried our favorite translator)), and I started getting 429 errors almost immediately. After searching for a while I noticed an interesting thing here https://github.com/akl7777777/bob-plugin-akl-deepl-free-translate/blob/main/src/main.js
starting on line 76.
You can also improve the translate_html function for this translator by dividing the string tags into separate lists, for example:
this is before<a href="#">this is job</a>this is after
Since the return is in the same order, by extracting the data we can put the tags in place and improve the quality of the translation
Let me know, what do You, guys, thinking about it.