Re: Using Windows Language Portal for IDE string translation

> > Also, I feel like you have missed the point with the MS translations -
they are professionally produced, accurate UI translations that MS uses for
their own products. This is the best kind of database for automated
translation.
>
> Personally I'm perfectly fine with this if doesn't generate dependency to
MS in the future.

Of course, it has to be compatible with GPL. I've emailed an account I
found on their site to ask about this, will say if I hear anything back. At
the moment the license seems _very_ unlikely to use with the GPL, but it
couldn't hurt.

> I don't know how well it will perform for complex sentences, Google's
engine is surely stronger but it can't be used unlimited and clients need
to be registered. These things are kind of green yet but an approach like
translating while parsing the docs for rendering (preferable with a free
engine, or a least free for personal use) solves synchronisation and effort
problems and would be easy than creating a platform for translations. Or a
step towards this last, I don't know, it's green, 'super green'.

Why expend effort for on-the-fly translation of technical documents when
people can just as easily copy and paste into an online translation service
like Google Translate or Bing Translator? You say it's easier, but it's not
without maintenance cost: it requires adding a new program to our
product/toolchain, and then maintaining its integration cross-platform. In
addition, you'd have to make sure that certain technical terms like the
names of methods and classes, the names of arguments and variables, and
other technical terms are not translated. What do you think about
performing a sloppy automated translation once as a starting point for
human translators?

---

Remember, all I'm trying to do in this case the goal is simply to get a
bunch of quick and easy translations into the IDE so that (1) that manual
translation labor can be saved and (2) people will see that we're actually
making an effort. So, without going through MS we could source UI
translations from another GPL-licensed codebase. Audacity for example has
these po files in their repo, which can easily be converted to the .qph
format Audacity uses: https://github.com/audacity/
audacity/blob/master/locale/it.po.

---

I have some thoughts on how to support documentation translation; I'll
start a separate thread for that.

-Brian


On Wed, Apr 4, 2018 at 1:59 PM, <[email protected]> wrote:

>
> 2018-04-04 11:15 GMT-03:00 <[email protected]>:
>
>>
>>
>> On Tue, Apr 3, 2018, 11:49 PM <[email protected]> wrote:
>>
>>> Hi Brian
>>>
>>> I just realised that to automatically translate and manually check the
>>> IDE could be a good solution. For the documentation, I think most used
>>> translators are offered as web service for free with some limits of
>>> quantity, but there is the Apertium platform (GNU):
>>>
>>> http://wiki.apertium.org/wiki/Main_Page
>>> https://github.com/apertium
>>>
>>> The wiki page is really not newbie friendly but I have used it for an
>>> installation art, it runs as a server in the local machine and works pretty
>>> well (there is even a ppa for Ubuntu). Maybe it could be used as a
>>> quark to translate the documentation then and there, it has language
>>> packages for many language pairs. I could try that and tell.
>>>
>>
>> Sorry, I genuinely have no idea what I'm looking at here; browsing the
>> wiki and GitHub only left me more confused. I found a "language pair list"
>> page which makes it sound like only a few languages are well-supported -
>> Spanishis that correct? If you think it could be useful maybe you should
>> try it out and explain what the workflow would look like.
>>
>
> Yep, that wiki is terrible, I know. I think it is in heavy development
> right now.
>
> The enter point is to install nightly builds repo, apertium, apertium-apy
> and languages data (see below).
>
> http://wiki.apertium.org/wiki/Apertium-apy/Debian
> http://wiki.apertium.org/wiki/Install_Apertium_core_using_packaging
> http://wiki.apertium.org/wiki/Apertium-apy
>
> I can't start the server as a service but the command:
>
> $ apertium-apy /usr/share/apertium
>
> works (that's hot new)
>
> There are many packages for languages pairs, in the repo are for example:
>
> apertium-en-es # i.e. lang data pair English-Spanish
> apertium-en-fr # i.e. lang pair English-French
> apertium-eng # IIRC with 3 letters are analyzers, generators, morphemes
> and taggers packages for each language or pair (don't ask me more)
> apertium-spa
> apertium-fra
>
> Languages progress have different states (incubator, nursery, staging)
> like Debian is not just Spanish.
>
> Then programs can make request and process the answer as usual:
>
> curl http://localhost:2737/listPairs
> {"responseStatus": 200, "responseData": [{"targetLanguage": "spa",
> "sourceLanguage": "eng"}, {"targetLanguage": "eng", "sourceLanguage":
> "spa"}, {"targetLanguage": "eng_US", "sourceLanguage": "spa"}],
> "responseDetails": null}
>
> curl 'http://localhost:2737/translate?langpair=es|en&q=está'
> {"responseStatus": 200, "responseData": {"translatedText": "It is"},
> "responseDetails": null}
>
> curl 'http://localhost:2737/translate?langpair=en|es&q=there+is
> <http://localhost:2737/translate?langpair=en%7Ces&q=there+is>'
> {"responseStatus": 200, "responseData": {"translatedText": " hay"},
> "responseDetails": null}
>
> I don't know how well it will perform for complex sentences, Google's
> engine is surely stronger but it can't be used unlimited and clients need
> to be registered. These things are kind of green yet but an approach like
> translating while parsing the docs for rendering (preferable with a free
> engine, or a least free for personal use) solves synchronisation and effort
> problems and would be easy than creating a platform for translations. Or a
> step towards this last, I don't know, it's green, 'super green'.
>
>
>> Also, I feel like you have missed the point with the MS translations -
>> they are professionally produced, accurate UI translations that MS uses for
>> their own products. This is the best kind of database for automated
>> translation.
>>
>
> Personally I'm perfectly fine with this if doesn't generate dependency to
> MS in the future.
>
> Best
> Lucas
>
>