Sure, I mean... my impression as indicated by the lack of response to the thread is that no one provides much expertise in javascript_catalog() these days (although it's only been a couple days). I don't use it myself so I do my best to review proposed changes and then we wait for bug reports. Maybe this will be the start of your journey to being that expert.
Quoting https://github.com/django/django/blob/master/CONTRIBUTING.rst, "non-trivial pull requests (anything more than fixing a typo) without Trac tickets will be closed! Please file a ticket <https://code.djangoproject.com/newticket> to suggest changes." On Friday, March 4, 2016 at 4:11:08 PM UTC-5, Cristiano Coelho wrote: > > Would a pull request be accepted? Does it need to be a new branch even if > the change is just a few lines? Does it need an open ticket first? > > El martes, 1 de marzo de 2016, 22:26:00 (UTC-3), Cristiano Coelho escribió: >> >> Looking through git history seems like the "always load english >> translations" code is quite a few years old. >> >> There's a 5 y.o ticket in here: >> https://code.djangoproject.com/ticket/16284 >> >> Which leads to here: https://code.djangoproject.com/ticket/3594 with a >> fix that adds the "discard if english not found" which doesn't resolve the >> issue completely if you actually have english translations but it is not >> the default language. >> >> There's also a link to here: >> https://groups.google.com/forum/#!topic/django-developers/1X_tPbhG_NQ >> proposing a change with no replies at all. >> >> I couldn't really understand why is it that the hardcoded english >> language can not be removed from here. >> >> In my opinion the code should be slightly changed to only load the >> default language rather than english (and as long as the requested language >> is not the same as the default one) as fallback, so it can match the actual >> server side behaviour, which will load the configured language (at >> settings) as a fallback language as long as it is different from it (an >> from english, which makes sense because django text ids are all in english). >> This change could however affect people that relies on always having an >> english translation as fallback when the configured default language is not >> english (does this even make sense? Would anyone do that?) >> >> After this change is done, there could be an improvement (for both js and >> server side translations) that some people might find useful, rather than >> always falling back to the default configured language, you could have a >> map of fallbacks, for example, if the user requests a portuguese language, >> but you only have english (default) and spanish (secondary), it makes more >> sense to fallback to spanish rather than english, but if the user requests >> russian, it makes more sense to fallback to english. >> >> El martes, 1 de marzo de 2016, 21:29:42 (UTC-3), Tim Graham escribió: >>> >>> Have you tried looking through history with git blame to find related >>> tickets? Another tip is to search Google with a query like >>> "javascript_catalog site:code.djangoproject.com". This will let you >>> find tickets to see if the issue was raised before. This is how I try to >>> answer questions like this since many of the original authors are no longer >>> active (or at least, you can find the person who authored the code in >>> question and try a more directed query like a ping in IRC). >>> >>> On Tuesday, March 1, 2016 at 6:23:38 PM UTC-5, Cristiano Coelho wrote: >>>> >>>> Maybe I wasn't clear neither, but the main issue is this: when using a >>>> language equals to the default one, and if that language does not define >>>> any translation text (because ids are the same as values so it is not >>>> necessary), the server side translations will always correctly return the >>>> translated texts, while the javascript won't because it always has an >>>> english fallback. >>>> Also the code I provided should actually load the default language >>>> translations as well (but not the english ones!) to make it behave exactly >>>> as the server side translations. >>>> >>> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0cab22c2-e833-42ff-b387-fb70cbb8f538%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
