Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jul 02 05:28
    nijel closed #4671
  • Jul 02 05:28

    nijel on master

    build(deps-dev): bump setuptool… (compare)

  • Jul 02 05:28

    nijel on pip

    (compare)

  • Jul 01 23:05
    dependabot[bot] labeled #4671
  • Jul 01 23:05
    dependabot[bot] labeled #4671
  • Jul 01 23:05
    dependabot[bot] opened #4671
  • Jul 01 23:05

    dependabot[bot] on pip

    build(deps-dev): bump setuptool… (compare)

  • Jul 01 06:31

    nijel on 3.7.1

    (compare)

  • Jul 01 06:28
    nijel closed #4670
  • Jul 01 06:28

    nijel on master

    docs: Release 3.7.1 (compare)

  • Jul 01 06:12
    nijel synchronize #4670
  • Jul 01 06:12

    nijel on gh-pages

    3.7.1 (compare)

  • Jul 01 06:10
    nijel synchronize #4670
  • Jul 01 06:07
    nijel assigned #4670
  • Jul 01 06:07
    nijel opened #4670
  • Jun 30 06:42
    nijel assigned #4668
  • Jun 30 06:42
    nijel assigned #4669
  • Jun 30 06:42
    nijel closed #4669
  • Jun 30 06:42

    nijel on pip

    (compare)

  • Jun 30 06:42

    nijel on master

    build(deps-dev): bump virtualen… (compare)

iteco
@iteco
Also there are no commits to pootle git in 9 months. Does he block also those ? Or did everybody just decided to stop on working o this project at the same time ? Earlier this was very vivid project..
Leandro Regueiro
@unho

@iteco AFAICT no project is hostage from anyone.

About that particular server I had credentials, but I've lost them. Anyway absolutely nothing prevents anyone from setting a different amaGama server somewhere else, since the project is free sofware. And you can even populate it with more projects and more up-to-date translations than https://amagama-live.translatehouse.org/ had.

Regarding everybody stopping working on Pootle, well the company we all worked for just shutdown like a year ago. And since then we all had to switch to new positions. In particular I find it difficult to find time and therefore I decided to focus my very little spare time to keep contributing to Translate Toolkit. But I definitely don't have the time to continue with Pootle or any of the other projects. There was a plan to release a last Pootle release and involve new people. I can tell you for sure I have no idea regarding Pootle's future, moreover taking in account there several other free translation tools around.

iteco
@iteco
@unho Thanks a lot about clarification! I suspected that (company closed), and I tried to look around for it, but I didn't find anything. I have been using pootle quite a long time (I found it years ago bitnami), and it is sad to give it up now when it has started to work. You did a good work. Thanks from it!
iteco
@iteco
If i remember correctly also mozilla was using pootle at some point, and there were also quite many other projects in amagama server. Do you know where they have migrated ? To weblate ?
Michal Čihař
@nijel
Mozilla has https://pontoon.mozilla.org/, not sure how about others.
I haven't noticed much projects migrating from Pootle at Weblate, most of projects which come to Weblate didn't use anything before.
phlax
@phlax
hi, just furthering what @unho said above - i have also moved on to other things. I tried for a while to figure out a model to support pootle development etc, but it wasnt working out. If anyone wants to take the baton and continue with dev - i will happily facilitate any required access
Stuart Prescott
@llimeht
Seems to be some failing ttkit tests with py3.7 btw. I'll try to look at them tonight.
Stuart Prescott
@llimeht
Hi! at https://bugs.debian.org/916745 / translate/translate#3254 , encoding problems with Python 3 and web2py are discussed. I'm a bit nervous that the patches change the bytes/unicode handling and that there might be further problems that this creates. I'd love some review before applying these patches to the Debian packages.
Stuart Prescott
@llimeht
Any thoughts on https://bugs.debian.org/916745 / translate/translate#3838 ? I really don't want to diverge in Debian without this being reviewed and preferably merged.
@nijel (simply because you seem most active at the moment....) any thoughts on the above?
Michal Čihař
@nijel
I think having tests covering the unicode strings handling as mentioned by @unho in review is way to go - that way we can clearly see whether it doesn't break anything
Ilia Shifrin
@protranslating
hi, looking for the best way to get source XLIFF segments parsed in python sending them one at a time to GCP AutoML via Google Translate API for a given custom-trained NMT model and then serializing the API responses back into the file
Got to a point when I can read a file and send it to Google Cloud to have translated with a specific custom-trained model and output into a separate file
but the file is plain text file and I need to do a bunch of custom model testing by getting XLIFFs translated with it retaining the format
found this guy's repo https://github.com/translate/pyliff
Ilia Shifrin
@protranslating
but it was last updated like 3 years ago and has this description "Currently XLIFF data can only be read. In future versions you will be able to manipulate the XLIFF data and serialize it back to a file." so it seems the dev gave up on it for whichever reason
anyone knows if a similar solution exists?
Ilia Shifrin
@protranslating
thinking of getting around with an XLIFF to CSV conversion but thought maybe there is an existing solution to work directly with an XLIFF
Michal Čihař
@nijel
@protranslating translate-toolkit can both read and write xliff
http://docs.translatehouse.org/projects/translate-toolkit/en/latest/formats/xliff.html
friedelwolff
@friedelwolff
@jason-p-pickering : I see you mentioned problems with amagama a while ago. I'm working on that now, so hopefully things are better soon.
It might already work now, but I'm still busy, so expect it go up and down for a little while longer.
Leandro Regueiro
@unho
https://twitter.com/leandroregueiro/status/1143135577107259394
Stuart Prescott
@llimeht
So given the latest release of ttkit breaks virtaal, is there any chance of a virtaal release soon? ;)
Stuart Prescott
@llimeht
(translate/virtaal@77c43a9 on its own cannot be cherry-picked; it needs some of the preceding patches too, which makes me nervous)
Leandro Regueiro
@unho
@llimeht Maybe you need to ping Friedel Wolff in GitHub regarding a new Virtaal release. I am not sure he reads this channel.
Allan Nordhøy
@kingu_gitlab
A new Virtaal would really do nicely
friedelwolff
@friedelwolff
I would really like to work on Virtaal again
Virtaal isn't packaged for some distros anymore (just recently saw it is not on fedora, for example)
I guess a flatpak would solve parts of the distribution problem
there are already several nice improvements in git since the last release
It is unfortunate that backwards compatibility was not important enough for the toolkit
friedelwolff
@friedelwolff
@unho By the way: I see you didn't announce the release on the mailing list. Did you manage to post? I recently was unable to post to a sourceforge mailing list.
Stuart Prescott
@llimeht
@friedelwolff we've still got a virtaal package for Debian and Ubuntu. I can drop in the newer version of that file into virtaal and it is probably OK (essentially cherrypicking 4 commits just to it).
However, Python 2 and gtk2 will both be going away in Debian and Ubuntu reasonably soon, I think, and that will force other action.
friedelwolff
@friedelwolff
@llimeht Yes. that is a bigger problem. The rewrite is a non-trivial amount of work. It comes down to three ports (pygtk -> gobject introspection, gtk2 to gtk3, python2 -> python3)
we struggle with providing long-term platforms in our world, it seems.
Stuart Prescott
@llimeht
yes, although I don't think we should say that any of the existing ones were short term platforms, hanging around for more than a decade ;)
(And it's better than Qt, which seems determined to kill off all Qt-using software with incompatible upgrades)
Mixing these 3 big transitions up is certainly a nasty challenge though. I've never done any gtk programming at all to know how difficult that might be. ttkit and friends are probably amongst the hardest things to do the py2→3 transition too :(
friedelwolff
@friedelwolff
well, I'm very comfortable with Python, so I don't mind that py2-3 migration too much
but it requires time
Leandro Regueiro
@unho
@friedelwolff I honestly didn't try to post on the mailing list.
@friedelwolff Regarding backwards compatibility there is a point when we should stop supporting everything. I sincerely hope this is another kick to get another Virtaal release out, this time including fixed requirements to avoid new TTK releases breaking compatibility for already rolled out Virtaal installs.
BTW, I have plans for removing support for Python 2 in any TTK release after Python 2.7 support goes away, which basically is 1st January 2020, which is in less than 6 months from now: https://pythonclock.org/
friedelwolff
@friedelwolff
@unho Of course there is such a point. We just disagree on where that point is.
fixed requirements won't help in the case of distros that want to upgrade the toolkit
I'd like to do a million things on virtaal, but my life went through multiple very disruptive changes in the last few years
Let's hope I can look into it more