It will be good if the libreOffice has translation feature like ms office. Sometime I want to see the translation of one word without need to go to firefox or other dictionary tools. It will be nice if it likes synonyms feature.
I'd like to add to this request with a little extension. Wordreference.com offers a per-term translation of really good quality, but does not (to my kowledge) offer web services. translate.google.com offers web services as well as a text block translation of arguably not excellent but acceptable basic translation. The Google translator toolkit (http://translate.google.com/toolkit/list?hl=en#translations/active) is a bit better at that. It also allows you to send an entire document (in a series of formats including .odt) and supposedly translates it for you then gives it back to you. However, that last feature breaks most of the style of any document you would submit to them. When translating a long user/technical documentation (for open-source projects in particular because this is really missing in general terms), a first part of the translation time is spent on finding basic phrasing of what is written in the other language. I personally think it would be great to have a feature to translate one paragraph at a time, using the translate.google.com API and maintaining basic formatting: alignments, bold, italic and specific styles applied (but excluding references, index markup, etc in a first version). There are many extensions I can see developing on top of that later on, but that would be a first shot. So the idea, in short would be, for the user: * Configure a Google translate API (or any other translation API, but for simplicity I'm developing the following based on one specific provider) * Configure (somewhere) the original language of the document * Configure the language of the document as the destination translation (normal LibreOffice feature to set document language) * Select a word or a whole paragraph * Click-right and select "Translate through Google(TM)" * The work or paragraph is changed, in-place, keeping all simple styling tags On the back-end side, when the command is launched: * Make sure the paragraph respects characters limitations, otherwise cut in chunks (preferrably on phrases separators) or ask the user to select a smaller part. * Get the original document language * Get the destination language * Get the list of languages ("from" and "to") from Google and ensure there is a match between local language defined and Google language * Send a call to translate.google.com 's API (http://code.google.com/apis/language/translate/overview.html) to translate the paragraph * Replace the selected text by the translated version returned by Google, trying to maintain the style as much as possible I have been translating documents for more than 120h in the last 45 days and I think it would really reduce my work of about 20% to have this kind of feature. As such, I am ready to put a $200 bounty on the development of this feature (payable through PayPal). Check with me if this is still true if you take this over in a long time.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
This feature is not implemented yet. Please don't close it.
Setting status to New
*** Bug 60631 has been marked as a duplicate of this bug. ***
FYI: there is an extension which might be helpful for implementing this feature: https://extensions.libreoffice.org/extensions/tradutorlibretext
Changing priority back to 'medium' since the number of duplicates is lower than 5
Great disadvantage in 6.4 for advaced users in relation to MSO 2019 Very important enhancement to do here for LO in future. Translated text should have the attributes of the original text in fonts and form. And this can do near 100% MSO 2019 with his service. The translate extensions are very old and without text attributes of original text. Google translator is a very good online engine. For me it is a major feature now and a critical feature in firms with international contacts.
https://extensions.libreoffice.org/extensions/anaphraseus How to use? very complicate extensions/tradutorlibretext do not go in LO 6.3 and 6.4 x64 on win 10-64 <class 'FileNotFoundError'>: [Errno 2] No such file or directory: 'C:\\Users\\stefan\\AppData\\Roaming\\LibreOffice\\4\\user\\uno_packages\\cache\\uno_packages\\lu18804wnwz0.tmp_\\tradutorlibretext%20(1).oxt\\TradutorLibreText.py', traceback follows File "C:\Program Files\LibreOffice\program\pythonloader.py", line 149, in writeRegistryInfo mod = self.getModuleFromUrl( locationUrl ) File "C:\Program Files\LibreOffice\program\pythonloader.py", line 94, in getModuleFromUrl fileHandle = open( filename, encoding='utf_8' ) (com.sun.star.uno.RuntimeException) { { Message = "<class 'FileNotFoundError'>: [Errno 2] No such file or directory: 'C:\\\\Users\\\\stefan\\\\AppData\\\\Roaming\\\\LibreOffice\\\\4\\\\user\\\\uno_packages\\\\cache\\\\uno_packages\\\\lu18804wnwz0.tmp_\\\\tradutorlibretext%20(1).oxt\\\\TradutorLibreText.py', traceback follows\X000a File \"C:\\Program Files\\LibreOffice\\program\\pythonloader.py\", line 149, in writeRegistryInfo\X000a mod = self.getModuleFromUrl( locationUrl )\X000a File \"C:\\Program Files\\LibreOffice\\program\\pythonloader.py\", line 94, in getModuleFromUrl\X000a fileHandle = open( filename, encoding='utf_8' )\X000a\X000a", Context = (com.sun.star.uno.XInterface) @0 } }
extension tradutoroootext.oxt do also nothing in LO 6.4.2.2 x64 win10-64
extensions/tradutorlibretext do not go in LO 6.3 and 6.4 and 7.0 x64 on win 10-64
the alternative in beta mode page translate https://extensions.libreoffice.org/en/extensions/show/pagetranslate So this is perhaps partly or fully resolved.
fyi: I see that LibreOffice based Collabora Online includes Translate from 22.05.7.2. It doesn't say if this will be in LibreOffice or their other LibreOffice based apps. https://www.collaboraoffice.com/code-22-05-release-notes/ Either way, another way to get LibreOffice with translate.
Since october 12, we have a new functionality in LO 7.5 : automatic translation using DeepL API. The commit implementing that is https://git.libreoffice.org/core/+/e20d2de7836da52dbf9e528d1043b1e188097bfd It is easy to configure the function, once you have open an account at DeepL. You can open a free account for 500.000 characters per month. So can we close this bug?
DeepL doesn't support a lot of languages, such as Arabic yet
(In reply to Fahad Al-Saidi from comment #19) > DeepL doesn't support a lot of languages, such as Arabic yet That's true, but DeepL adds more and more languages. I can't believe, that we will find better solution for LO, but I'm not a developer.
*** Bug 154879 has been marked as a duplicate of this bug. ***
The feature has been implemented with DeepL in LibreOffice 7.5, and although Arabic is a major language that DeepL should really offer, no service will offer all existing languages. New, more specific reports can be opened to improve the new feature, like supporting more languages, or to allow using a different machine translation service and API. For example, LibreTranslate is open source and recognises Arabic: https://libretranslate.com/ Fahad, could you please open a new report? Closing this report as resolved. (can't CC Mert Tumer as they don't seem to have a Bugzilla account)
for sure here it is https://bugs.documentfoundation.org/show_bug.cgi?id=155058