| 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/translate-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/28708/error-when-creating-users |
| 14:05 |
Dyrcona |
So, I finally hit this: https://bugs.launchpad.net/debian/+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 |
