Log file Viewer

[11:22:43] <dstufft> jezdez: Is there any better way to handle translations when you want a link inside the translation than something like _("This is a <a href="%(url)s">sentence to be translated</a>.", url=whatever) ?

[12:13:02] <jezdez> dstufft: yeah, something like l20n.org

[12:13:19] <jezdez> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/L20n/HTML_Bindings

[12:14:09] <dstufft> whoa

[12:14:16] <dstufft> does this do the translation client side?

[12:16:59] <dstufft> okay this is cool

[12:18:09] <dstufft> oh hey, if we do the localization in the client side, then the HTML won't change per language and everyone will get the same cached page

[12:20:01] <dstufft> jezdez: are you involved in this project at all?

[12:20:31] <jezdez> I’m not, some other people work on this

[12:20:42] <jezdez> the html doesn’t need to change per language

[12:20:54] <jezdez> since you’ll be able to automatically change it client side

[12:21:06] <jezdez> you only provide the raw data for the strings

[12:21:28] <dstufft> I'll open a bug then, one of the links is 404ing :)

[12:22:02] <jezdez> oh :(

[12:22:06] <jezdez> check out http://l20n.github.io/tinker/

[12:22:18] <jezdez> each strings on the left is rendered on the right

[12:22:49] <jezdez> http://l20n.org/learn/ is also ok

[12:23:01] <dstufft> responsive localization is pretty cool

[12:23:05] <jezdez> https://github.com/l20n/l20n.js/blob/master/README.md is a good step by step

[12:23:18] <jezdez> yeah, it’s supposed to be the future ;)

[12:23:30] <jezdez> the general idea is that gettext is way to specific to compiled languages

[12:24:00] <jezdez> and doesn’t really work well with responsive design and varying client rendering

[12:24:17] <jezdez> plus it simply doesn’t map a few exotic language features

[12:24:32] <jezdez> like masculine and feminine differences in words

[12:24:50] <dstufft> if english doesn't need that feature, no language needs that feature

[12:24:57] <dstufft> (right? RIGHT? :(()

[12:25:40] <jezdez> heh

[12:25:41] <jezdez> right

[12:25:51] <jezdez> think african or asian languages

[12:25:58] <jezdez> btw there is https://github.com/l20n/python-l20n

[12:25:59] <dstufft> jezdez: OK, so with my like 2 minutes of reading, l20n.org seems 100% better than {{ _('foo') }} all of my jinja templates

[12:26:10] <jezdez> but it seems quite underengineered

[12:26:28] <dstufft> so I'm gonna switch to this

[12:26:31] <jezdez> yeah, fwiw, jinja2 just follows best practices from the GNU world like django does

[12:26:40] <jezdez> gettext is a gnu tool afterall

[12:27:32] <dstufft> I don't think we'll need python-l20n because I don't think I'm embedding any user facing strings in Python, It seemed like a better idea to just have them all in the templates to make it easier

[12:28:20] <dstufft> jezdez: btw, did you see the new design for warehouse?

[12:28:58] <jezdez> yep, agreed on separating the html stuff and translations

[12:29:00] <jezdez> if you combine this with something like pontoon.mozilla.org

[12:29:12] <jezdez> that offers on-page translation for translators

[12:29:48] <dstufft> oh neat

[12:29:56] <jezdez> the translated strings are stored in a backend and then able to be extracted as l20n entities

[12:30:20] <jezdez> the tool is a bit tightly coupled with mozilla’s projects right now though :-/

[12:30:31] <jezdez> but I wonder if there are other projects out there doing that

[12:30:54] <jezdez> yeah, I had seen the new design, glad it’s coming along

[12:31:06] <jezdez> kind of sad I did not get the chance to spend more time on pypa stuff :(

[12:31:09] <dstufft> I haven't really bothered to set up a framework to actually do the translations yet, just been marking everything with _() so that we can translate it if people step up to contribute translations

[12:31:19] <jezdez> yeah, that’s a great first step in any case

[12:34:21] <dstufft> I'm pretty useless for doing anything but make it possible for someone else to translate it since I'm pretty sure replacing everything with "guten tag" and "guten morgan" which is the extent of the German I remember isn't very useful :D

[12:37:27] <jezdez> hah

[12:37:28] <jezdez> yeah :)

[12:37:54] <jezdez> remember knowing other languages isn’t required to be a good OSS citizen about allowing others to use their own

[12:39:45] <dstufft> ya

[12:40:52] <dstufft> PyPI is important enough that I'm sold on making sure it's able to be translated :D I just hope it ends up being useful because I'd love for more people to be able to user PyPI more effectively/easily

[12:42:59] <jezdez> fwiw, I guess the question is if the main python side will ever be non-english

[12:43:08] <jezdez> have you talked to the owners of that site?

[12:43:28] <jezdez> since it may be disturbing to have one site in native language and not another

[12:45:13] <dstufft> Nope, I generally treat PyPI as it's own distinct thing (even though it's not really). Probably that should happen though

[13:04:38] <xafer> Hello jezdez, since you're here, any clue/memory of https://github.com/pypa/pip/issues/404 ? (I'd be glad to close it if you can't remember ^^)

[13:06:10] <ronny> dstufft: the amont of german that jezdez and me remember should be more than enough to be dangerous :P

[13:19:04] <jezdez> xafer: oh man, that’s a long time ago

[13:19:08] <jezdez> no idea

[13:19:15] <jezdez> closing..

[13:20:44] <xafer> thanks ^^ only 505 issues left :-|

[13:23:30] <jezdez> yay!

[13:23:39] <jezdez> thanks for your help xafer

[13:25:53] <xafer> happy to :) But I would be happier if the number actually decreased, while it nicely stays at ~500 :-/

[13:44:58] <dstufft> well if people would stop finding ways to break pip it might start going down!

[13:49:12] <ronny> fml

[13:50:12] <ronny> how can i make pip 7 download wheels if possible but NEVEE EVER use the wheel cache it builds locally in a reliable way without uninstalling wheel

[13:50:34] <ronny> i have to do a networkless install and a setup-requires is breaking the server side

[13:53:15] <dstufft> ronny: --no-cache-dir ?

[13:56:39] <ronny> seems to work, i recall there was a problem last time i tried

[14:14:40] <xafer> dstufft: what do you mean by `pip install implicitly does a "minimal" upgrade?` (in issue 59)

[14:16:53] <dstufft> xafer: I already have foobar 1.0 installed on my computer but foobar 2.0 is available, I type ``pip install foobar`` and it upgrades me to foobar 2.0 (but it's a minmal upgrade, so it only upgrades foobar, not any of it's dependencies unless it actually needs to to satisify constraints)

[14:17:11] <dstufft> IOW, in what situation do I want to use the latest version if something is not installed, but an older version if it is

[14:18:07] <xafer> so you would like pip install to change to the proposed pip upgrade behavior ?

[14:20:30] <dstufft> I'm sort of leaning towards that yes. I'm not 100% on it but I'm sort of thinking that it might make the most sense. I'm trying to think of when I want the current behavior instead of the pip upgrade behavior and I can't really think of a time except for weird edge cases. It appears that apt-get and yum and dnf do the same thing (apt-get install foo where foo is already installed will upgrade foo) which seems to lend some weight to the idea

[14:21:09] <dstufft> Other than the backwards compat thing (which isn't unimportant) I think it probably is the least ugly

[14:21:56] <xafer> and --upgrade could stay the same :)

[14:23:15] <dstufft> --upgrade could continue to do a recursive upgrade yes (though we'd probably want to hide that option and make it an alias for something like --recursive, but we could have a really long deprecation cycle on --upgrade since the cost of a hidden alias is really low)

[14:25:43] <xafer> seems sane, so we would get the same end result from "pip install something" whether something is installed or not

[14:25:51] <dstufft> yes

[14:25:57] <dstufft> well

[14:25:58] <dstufft> mostly

[14:26:14] <dstufft> if one of the dependencies is installed we won't upgrade it unless need be

[14:26:24] <dstufft> but we'll get the same result for the items listed on the command line

[14:27:10] <xafer> :-/

[14:28:35] <dstufft> So it'd be mostly the same result, except we'll minimize churn for things not explicitly mentioned

[14:28:46] <dstufft> unless you pass --recursive/--upgrade

[14:30:47] <xafer> I'm uncomfortable dealing with them differently

[14:31:14] <xafer> I'm leaning towards your --upgrade-strategy option now

[14:31:49] <xafer> which could also provide a solution for https://github.com/pypa/pip/issues/3188

[14:35:20] <xafer> with "minimal" being the default i.e. only upgrade if specified

[14:35:21] <dstufft> Why uncomfortable? There is a pretty clear differentiator in whether you've mentioned the package explicitly or it's only being pulled in implicitly which makes sense to me

[14:35:57] <dstufft> I'm not sure that --upgrade-strategy is a great for for #3188, because you need a "reverse" option for every strategy

[14:37:17] <dstufft> so you'll need --upgrade-strategy mimimal and minimal-reverse and recursive and recursive-reverse

[14:39:01] <xafer> and --maximal-if-on-command-line-minimal-if-a-dependancy + reverse :p

[14:45:43] <dstufft> (I'm pretty sure this behavior matches what apt-get/yum/etc does fwiw)

[15:00:38] <xafer> well it seems strange to me that pip install django will always give you the latest version but pip install on something that depends on django will leave you with the one currently installed

[15:00:51] <xafer> but why not :)

[19:31:56] <xafer> A few PR to review, #3173, #3187, #3203, #3211 and #3213 if anyone has time, they are all fairly small (less than 100 lines)