Crowdin TranslationService integration about serge-plugins HOT 16 CLOSED

That's an interesting question. I wonder why "source" is needed for .po files at all, since .po files are bilingual (i.e. each .po file can be used as a source). I looked at Crowdin docs at and they even have this example with "English .po files" (https://support.crowdin.com/configuration-file/#language-mapping) which doesn't make sense.

@elyzov-plesk is Crowdin the only platform you want to try to integrate Serge with, or are you open to try out some more appropriate CAT tools?

from serge-plugins.

@elyzov-plesk Take a look at the example in the test folder for crowdin.

from serge-plugins.

Also, for now, in order to have everything working properly, I would suggest using my fork of serge https://github.com/dragosv/serge. My fork supports the xliff format, that is better supported by most other providers except Pootle.

from serge-plugins.

Let's use https://gitter.im/serge-plugins/Lobby for discussions.

from serge-plugins.

In order to have crowdin working you will need (with my fork)
Serge config

ts_default_lang_file        YES
source_ts_file_path        ./crowdin/source/%PATH%%NAME%.po 
ts_file_path                     ./crowdin//target/%LOCALE%/%PATH%%NAME%.po

crowdin config

"project_identifier" : "serge_test"
"api_key" : "1234567890abcdefghklmnoprstuvxwy"
"base_path" : "./crowdin"

"preserve_hierarchy": false

files: [
{
  "source" : "source/*.po",

  "translation" : "%two_letters_code%/%original_file_name%",

  "languages_mapping" : {
    "two_letters_code" : {
      "crowdin_language_code" : "local_name"
    }
  },
}
]

from serge-plugins.

The ts_default_lang_file, source_ts_file_path are new properties that I've introduced (they are PR for serge EvernoteArchive/serge#80, EvernoteArchive/serge#79)

from serge-plugins.

The problem with suggested ts_default_lang_file and source_ts_file_path is that they try to introduce concepts that should not be there in the first place. Both .po and XLIFF are bilingual files, so there's no such a thing as a "source .po" or "source .xliff". If some translation service has such a notion, I'd advise asking them to fix the way they deal with bilingual files in the first place.

If some of such services require a notion of a 'source directory' before they are fixed, I'd recommend implementing this workaround logic in the sync plugin itself (and document that this is a hack that has its caveats, see below) rather than to legitimize the incorrect approach to "source .po" or "source .xliff" through adding core settings.

Note that in Serge .po (or .xliff) files can be different on a per-language basis. That's a feature. You may want to selectively translate certain resource files only into a subset of languages, or you may want to provide some language-specific comments to linguists. This will all lead to having different set of translation interchange files (be it .po or .xliff) between languages, and Crowdin won't be able to deal with this scenario.

(I'll update both PRs with the information above).

That's why I initially asked @elyzov-plesk if Crowdin is the only option to consider. Because right now choosing any translation service or tool that can't properly handle bilingual translation files will result in hitting this limitation in the future.

from serge-plugins.

Most providers need a source file, unfortunately. For example, I am using Mojito and it is not an option to use Pootle due to specific functionality (project requests, exporting/importing needed translations). Also, I used Crowdin in the past and it is a business decision, as it allows to use external translation agencies (this applies to other commercial offerings) plus the added functionality.

from serge-plugins.

Plus hosting an internal software exposed to the world is a security risk. Therefore an open source software translation software is not an option for a lot of companies.

from serge-plugins.

@iafan Please reconsider the PR's that were closed, as it blocks integration with the other providers.

from serge-plugins.

Note that it is possible to generate a 'source' translation file by simply introducing a new language, e.g. en-src, or src as a target one. This will have it generated.

Also, after chatting with Crowdin support, it seems they allow one to use the same .po file both as a source and a target thus not requiring a dedicated source language (though this is still a hacky way to work with .po files).

You can install Pootle (or Zing) on an isolated server. Security-wise it will be the same as using any cloud service. Or you can install it behind the corporate firewall without external access, and give a VPN-only access to this server.

from serge-plugins.

Again, Pootle is not an option due to various aspects to many organizations. While Serge is an internal tool (used by the dev team let's say) the Translation Service is used not only by the organization but also by external parties.

from serge-plugins.

The new artificial language is a hack. Also, the structure of the sources and targets differs. I want this to be straightforward. Hacks should be used only on edge cases, but this is mandatory for five Translation Services integration with Serge (under serge-plugins).

from serge-plugins.

And plus two others that I have under work (GetLocalization and Smartling) require the same hack. That makes it 7 translation providers already.

from serge-plugins.

Also, the hack requires a PR that has not yet been merged
EvernoteArchive/serge#72

from serge-plugins.

@dragosv, thanks a lot! Your serge fork and ts_default_lang_file, source_ts_file_path options solved my problem!

from serge-plugins.