I forgot to push. I’ve also pushed a change to the pootle repository - remember.py would use 100% cpu and didn’t work properly.
Well, I got it to work with MariaDB, which does seem to produce the TIMEOUT error quite reliably, but for me the following change does eliminate the CACHE_TIMEOUT error under MariaDB:
edit ~/.pootle/pootle.conf
Under the CACHES section, replace:
'BACKEND': 'django.core.cache.backends.db.DatabaseCache',
with:
'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
That’s all. It reduces the number of things the database is being used for, and seems to resolve the CACHE_TIMEOUT problem.
That sounds excellent. Do whatever is most convenient for you as long as it is consistent. Note that pootle comments are not written to the .po files, they are kept in the pootle database, this is far from an insurmountable issue though, for example comments are easily extracted from the JSON from pootle dumpdata, and they are linked directly to the filename and via a key to the msgid/msgctxt. I think pootle comments would be a convenient way to do this, and what I would suggest is making the first comment on the first entry the description.
Do you mean the sutta title? 'cos that’s where I was thinking of doing it. I have been very occasionally using the comments field for actual comments, mainly in places where I disagree with BB’s translation. If I keep these out of the “title” comments, will it still be easy to extract them? Or would using some identifier help? Or is it best just to have no comments apart from the descriptions?
One advantage of using the comments field over a separate file is that it makes it easy for subsequent translators to use for the same purpose, but only if the usage is clear and unambiguous.
Yeah, in practice.
Easy enough for me. You can also add a translation comment on the title but after the description comment, as I said “first comment on the first entry” would be description, anything subsequent being ignored.
Excellent, that does it. Now running on MariaDB. Everything is much snappier, before there was always a lag, I assumed it was the browser, but obviously it was the DB. And the “move ten up and down” works great, too.
I still hate working with databases though. Just sayin’.
So a minor question here for @blake .
I think I mentioned some time ago that Pootle says it supports markdown, which would be great at some point. Right now, however, I’m finding that occasionally I’m wanting to write lists, and there’s no convenient way of doing it. So I can just write the HTML, fine. But I’m wondering if we can just do it more simply.
What if I put some sign, say a ~ at the beginning of each list item. The item ends with the next major punctuation (;:—.?!)
~ is convenient because it’s not used in the PO files at all, I think. Then we can just convert this to an HTML <ol> later.
Let me know if you think this is a good idea, otherwise I’ll just write the HTML.
I think pootle supporting markdown is in the context of static pages and perhaps templates, I would presume the translated strings would always be treated as plain text.
I think you could just use the hyphen since we don’t really use hyphens in the text content (they appear in the HTML, but this is irrelevant).
However using HTML has the advantage of being very explicit and since this is html5 you don’t need bother with </li>, you only need the </ul> at the end.
I’ll leave it up to you, but it’s certainly not hard to convert markdown style markup into HTML - with one provision - it becomes harder to perform the conversion reliably if the list spills over multiple msgstrings, probably safer in that case to use real HTML.
Okay, well that’s good anyway. I’m doing a static page for translators’ guidelines and markdown would be perfect. But maybe wait for 2.7.
Which, BTW, is out already. I’m thinking that when I break to come to Europe, we can take the time out to upgrade.
Yes, I’ll bear this in mind.
Pootle 2.7.0 was buggy as heck, as in you had to muck around with configuration and probably fix a bug or two just to make it kind of work. They’re up to 2.7.2 now and working on 2.7.3, so development is fast.
I’ll probably take another crack at installing it soon and see how it is progressing.
No worries, no hurry.
One minor detail for the next iteration. We should extend the autocorrect for quotes to include:
- ellipsis: … → …
- en-dash: – → –
- em-dash: — or –- → —
When, down the track, we start working with other languages, we’ll have to work out autocorrects for the different kinds of quote marks.