Evergreen ILS Website

IRC log for #evergreen, 2017-09-02

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
05:01 pinesol_green News from qatests: Test Failure <http://testing.evergreen-ils.org/~live>
09:42 bshum gmcharlt: I added POT updates to working branch user/bshum/20170902-i18n-pot-sync
09:43 bshum There's a few areas I'm still reviewing, the one that I question most is this in one in Open-ILS/src/templates/staff/base_js.tt2
09:43 bshum msgid "{{location_name}} ({{owning_lib_shortname}})"
09:44 bshum Just another case where we only seem to be sending the variable names for translation. And the PO not likely to ever contain the actual values for those variables, so eh...
10:14 * bshum reads up on PO filter and various tests we could try to use to validate our PO files to prevent i18n mishaps... http://docs.translatehouse.org/projects/transla​te-toolkit/en/latest/guides/using_pofilter.html
11:00 Dyrcona joined #evergreen
11:01 Dyrcona So, I upgraded one of my development branches with latest master this morning.
11:01 Dyrcona I did a fresh load of concerto, and I'm getting no search joy.
11:02 Dyrcona I search for mozart in the web staff client and the browser says, "Waiting for host..."
11:02 Dyrcona Looking at the osrfsys.log and postgres, it looks like the search finished and returned results.
11:03 Dyrcona After typing all of that, I see I have an internal server error.
11:03 Dyrcona I'll see what that's about.
11:05 Dyrcona Nice! Lots of noise about undefined values.
11:07 Dyrcona Are any new configuration changes required since July or so?
11:11 Dyrcona Is qstore required for search, now? Or, is that in the future? That looks to be the main difference I see.
11:14 gmcharlt Dyrcona: qstore is needed for user buckets and batch user editing, but not search
11:16 Dyrcona gmcharlt: OK. I've enabled it. I'm checking opensrf_core.xml for differences before restarting things.
11:17 Dyrcona Nothing big there, just the new auth login service.
11:18 gmcharlt bshum: in retrospects, [% l("'[_1]' ([_2]')", '{{location_name}}', '{{owning_lib.shortname}}') %] might be better
11:18 Dyrcona emerge-files++
11:22 Dyrcona After starting qstore this is looking the same. I may just build a fresh VM after this to clean up any crud and try just master without my modifications.
11:22 Dyrcona Ooh... Now, I get "blank" results. A list of numbers with no text.
11:23 Dyrcona In the OPAC, it works...
11:24 Dyrcona I'm getting screen shots to share.
11:24 Dyrcona Ran the mozart search again...
11:24 bshum gmcharlt: I suppose so, or we just need to make a note for new i18n practice to ignore anything in {{variable}} and that should be good too
11:25 gmcharlt yeah
11:25 bshum I just finished building a new test server based on the branch with the POT changes and it seems to be perfectly fine to me
11:25 bshum I think we can safely push it in for now and figure out next steps
11:25 gmcharlt and arguably, {{username}} gives a translator more of a fighting chance to figure context than a bare [_1]
11:25 bshum Yeah I get the argument, but I also don't think it's realistic that any actual values would ever end up in the PO file that way
11:26 pinesol_green [evergreen|Galen Charlton] LP#1251394: fix typo in seed data caugh by t/24-sql-gettext-unique.t - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=d5fe1cc>
11:26 gmcharlt but regardless, that's definitely an area where it's all too easy for translators to break stuff at no real fault of their own
11:27 bshum I mean the way tt2 translates stuff now, a value of "admin" or "bshum" won't end up in the file to be translated for username.  And I definitely don't expect to see library shortnames end up in the PO file either.
11:27 bshum So it seems like we're setting things up to never get translated anyways
11:27 bshum in-db translation approaches work differently
11:28 bshum But I don't know if we have the architecture to support translations for these fields
11:28 gmcharlt well, yes - the issue would be more a translator taking things too literally and doing {{nombredeusario}} or the like
11:29 Dyrcona Ah, bummer. The site I used to use for pasting images is no more.
11:29 Dyrcona My link checker failed me, 'cause it redirects to the TLD registrar.
11:29 bshum gmcharlt: Right, that did happen.
11:31 bshum I just mean it doesn't seem to serve a purpose to mark the string translatable when it's just variable code
11:31 bshum Just seems misleading, and prone to cause problems if someone does mistranslate it
11:32 gmcharlt it may be an excess of a caution, but punctuation convenstions are not universal
11:32 gmcharlt and (spitballing) a translator might find "$loc de $biblioteca" better than "$loc ($biblioteca)"
11:35 bshum I guess that's a logical reason.  Consider my concerns calmed for the moment.
11:36 bshum I'll go back to tinkering with those PO filter checks I noted earlier then.  Maybe that'll help us craft stuff to prevent translator oops with the variables.
11:48 Dyrcona I bugged it: Lp 1714699
11:48 pinesol_green Launchpad bug 1714699 in Evergreen "Looks like something recent broke search in web staff client" [Undecided,New] https://launchpad.net/bugs/1714699
11:50 bshum That is strange
11:52 bshum Dyrcona: I get results in my web client catalog search
11:53 Dyrcona bshum: When did you build?
11:53 bshum I based it on my i18n POT sync which is built on top of master around 9 am or so
11:54 Dyrcona I rebased a little bit later, so nothing should be different between ours.
11:54 bshum Right
11:54 bshum Did you upgrade your DB?
11:54 Dyrcona I built a fresh db.
11:54 Dyrcona reloaded concerto.
11:54 bshum Oh, hmm.... weird
11:54 Dyrcona I'll comment that on the bug.
11:55 Dyrcona I'm not sure how the db would matter, though. I'd think that would break the OPAC, too.
11:56 bshum Yeah definitely seems to be working fine for me in both places
11:56 gmcharlt likewise for me on a fresh DB on Jessie
11:56 gmcharlt but bug 1709710 may be relevant
11:56 pinesol_green Launchpad bug 1709710 in OpenSRF "Default ejabberd max_stanza_size can be exceeded when chunking (MARC)XML-heavy responses" [Undecided,Confirmed] https://launchpad.net/bugs/1709710
11:56 gmcharlt Dyrcona: and I'm wondering if either applying the OpenSRF patch in that bug or bumping up max_stanza_size would resolve the issue you're seeing
11:57 Dyrcona But, wouldn't that also affect the OPAC results?
11:57 bshum It's not a weird cache issue right?
11:58 Dyrcona I can try it, later. I think the rest of my day is going to be taken up by other things.
11:58 gmcharlt doing weekend things on your weekend? horrors! ;)
11:58 Dyrcona bshum: I don't think so. Before I adjusted my opensrf.xml, I got an internal server error with the web staff client.
11:59 Dyrcona What cache do you think would be acting weird?
12:00 bshum Browser?  :)
12:00 bshum But anywho
12:01 bshum A lot of stuff got merged yesterday, could be any number of new things I suppose
12:01 bshum Why July btw?
12:02 Dyrcona 'Cause that was when I last updated my opensrf.xml.
12:02 Dyrcona I'm seeing some weirdness in my local checkout of my branch.
12:03 Dyrcona It shows a lot of files changed that I didn't touch.
12:03 Dyrcona Maybe my branch is fubar after the rebase?
12:03 * Dyrcona fires up the vm to see what the branch looks like on there.
12:04 Dyrcona It looks about tright.
12:04 Dyrcona right, even.
12:06 Dyrcona So, on my laptop, git status reports 11 files changed.
12:06 Dyrcona git diff only shows the difference for the 1 file that I did actually change since force-pushing the branch.
12:07 Dyrcona I suppose a git gc may be in order?
12:09 Dyrcona Heh. Nice. Everything I find online says, "You're toast. Nuke it from orbit and start over."
12:12 Dyrcona Resetting the branch seemed to work, though.
12:12 Dyrcona I'll have to fiddle with a new build later.
12:16 Dyrcona IDK. Maybe I should just wipe out my local repos and start fresh?
14:04 Dyrcona joined #evergreen
14:04 Dyrcona Too funny: https://www.ejabberd.im/forum/2​8708/error-when-creating-users
14:05 Dyrcona So, I finally hit this: https://bugs.launchpad.net/debia​n/+source/ejabberd/+bug/1659801
14:05 pinesol_green Launchpad bug 1659801 in ejabberd (Ubuntu) "apparmor rules block ejabberdctl" [Undecided,Fix released]
14:05 Dyrcona Even using sudo....
14:05 berick Dyrcona: sudo ejabberd
14:06 Dyrcona berick: Yeap, thanks.
14:06 Dyrcona First time it failed for me with just sudo.
14:14 Dyrcona I wonder if that person asking on the ejabberd forum ever got help? They mention OpenSRF in their post.
14:15 Dyrcona yay! OpenSRF works. :)
14:15 Dyrcona And company just arrived, so got to go, again.
17:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
18:33 cucumberjoe joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat