Re: [Mailman-Developers] Translating notifications raised by mailman-core in postorius
On May 17, 2016, at 11:15 AM, Simon Hanna wrote:
>Theoretically the core could translate the messages before passing them
>to postorius. This would require core to know about the language it
>should translate to. I don't think this is a very good approach because
>we would have to make sure we offer the same languages for core and
>postorius and I'm not sure how we would pass the languages to core...
Probably Accept-Language could be used to specify that, but I (think I) agree
it's not the right approach. My only hesitation is to remember that Postorius
isn't technically the only web front-end that could be connected to the core.
If some homegrown ui also wanted translations, it's not clear how much they
could leverage of existing work if all the translations lived in Postorius.
>I propose core to return an error code with each request. That way
>postorius can add strings for all the errors that it cares about and
>translate them accordingly. This would require an api change. Since 3.1
>would change the api anyway, it would be nice to include the changes there.
If we're going to return an application-specific error code (in addition to
the HTTP response code we already return), then I think it means we'll be
returning a JSON structure even on error conditions. Right now, JSON is only
returned on success, and strings are returned on errors.
If we say in API 3.1 that JSON is always returned, then we have some
additional options. What makes the most sense to me would be to always return
a dictionary with some well-defined keys. That at least gives us a chance to
evolve the API probably without having to rev the API version in the future.
One problem with returning Mailman-specific error codes is that we'll need *a
lot* of them. Essentially one for every error condition in the REST API.
I've always found such arrangements a nightmare to maintain and debug. Error
codes have no obvious meaning so the mapping of code to meaning always has to
be looked up. We could segment the error space so that there's some semantic
equivalence (e.g. 01xx means a list-specific error, 02xx means a
membership-specific error, etc.) but there's always some twisting that goes on
the keep those up-to-date and meaningful within the semantics we give them.
And it's still not enough, because as you point out, there is always going to
be variable data that has to be associated with the error. A good example is
when a mailing list is created within a nonexistent domain. The error reason
is something like:
'Domain does not exist: example.net'
which gets interpolated on the server side. So obviously an error code like
0135 won't help because you could only translate that to 'Domain does not
exist' without also knowing the name of the domain that failed.
So now we also have to include some variable data in the JSON response. Which
leads me to think, why do we need error codes when we already have a format
perfectly suited to the cause, and which we already use internally for other
translatable contexts, i.e. PEP 292 strings ($-strings).
Thus, our error responses could be something like:
{
'reason': 'Domain does not exist: example.net',
'template': 'Domain does not exist: $domain',
'data': {
'domain': 'example.net',
},
}
'reason' would always be the interpolated English (i.e. source) string.
'template', and 'data' should be obvious. We need a separate namespace for
the interpolation data.
A front-end could just use the English reason, or it could translate the
template and interpolate the data dictionary into it.
Making this change would be a lot of work, but it could be done in several
branches.
One branch would provide the infrastructure to return JSON error responses.
These would only be done for API 3.1, and possibly you'd also want to check
the Accept header to make sure the client is prepared to accept JSON. Then
all of the error reporting call sites would have to be changed to pass in the
template and data dictionaries, with the helpers doing the interpolation for
'reason' and the setting up of the response correctly. Then tests and
documentation. :)
If you like the general approach we can hash out implementation details.
Given however that Pycon is near and I *really* want to get 3.1 out during
Pycon and there are already at least two big features that still have to be
added (unsubscription workflow and template support), it might be better to
defer this to core 3.2 and API 3.2. That way, we can get it right without
rushing it in.
Cheers,
-Barry
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [Mailman-i18n] Translation of Mailman 3
Hi Simon, On May 17, 2016, at 03:31 PM, Simon Hanna wrote: >I guess I could take some sort of lead on that. I played around a little >with pootle and I really like it. It's easy to use, fast and anyone that >registers can start translating. Just by way of comparison, have you played with Zanata yet? How would you compare the two systems? >The main question would be selfhosting vs using gnu's hosted version. I'd really prefer not to self-host. I don't think we're a big enough organization to commit to long-term maintenance. I'm not at all questioning your eagerness, abilities, and availability, but life has a way of throwing curve balls at us[*] and I worry about 5 years in the future if interests or availability changes. Also, I wonder if we wouldn't be giving up some economies of scale by sharing translation infrastructure with other projects. >If you want I can spin up an instance on my server and provide >interested people credentials to play with. (existing demo instances >don't allow adding/managing projects) If the i18n community wants to play with a pootle, I think that's fine. We can certainly use it to compare against other services. >From my perspective, I don't have too many requirements, other than that we can upload .pot files and download .po files when it makes sense for the project, which would be disconnected from the timeline for translators to submit translations. Right now for MM2.1, Mark has to request updates timed to his releases, and I really want to avoid that. IWBNI whatever system we choose had nice git integration, but that's not required. My only other requirement is that whatever we choose be comfortable enough that translators *want* to use it. As a pretty typical monolinguist, I'm definitely not qualified to judge that. Cheers, -Barry [*] Is that a euphemism that translates outside of North America? ;) ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [Mailman-i18n] Translation of Mailman 3
On 04/21/2016 04:47 AM, Stephen J. Turnbull wrote: > -i18n removed, I'm not subscribed. > > Barry Warsaw writes: > > > We need a Mailman 3 translation champion, someone who understand > > the technical and more importantly, social issues involved, and can > > spend time and energy on helping bring a good story to fruition. > > I'm happy to give wide latitude to the champion to help shape a > > solution that works for us. Maybe that's you Simon? > > I can help somewhat, I know the technology, I have a "friend in the > business" (a lawyer buddy who's heavily invested in legal translation > software), I've been involved with the Mailman and Debian translation > communitiess in the past. But right now I'm "busy as Barry", and for > the near future GSoC is going to sop up most of my Mailman time. I guess I could take some sort of lead on that. I played around a little with pootle and I really like it. It's easy to use, fast and anyone that registers can start translating. The main question would be selfhosting vs using gnu's hosted version. GNU is using v 2.5. 2.7.3 is the current version which changed quite a bit. The newer version has some sort of revision support has the ability to add comments to translations. The biggest change is that adding new files/ updating them requires filesystem access in 2.7.3 So I think that GNU is going to stick to 2.5 for the time being. Selfhosting would have a couple of upsides * Easier access to generated po files (scriptable) * Easier upgrade of po files * More features (v2.7.3) pootle has a couple of features that I think are nice to have. * Offline translation support (they have a very nice peace of software called virtaal) * Terminology support (we provide recommended translations for common words) * Used by (big) organizations (mozilla, document foundation, ...) * Relatively fine grained permissions (users can get permissions based on languages as well as projects The trend seems to be to use self hosted pootle servers, at least mozilla and libreoffice do, there are probably more. I don't think selfhosting would be that hard. It's based on python+django and uses redis. If you want I can spin up an instance on my server and provide interested people credentials to play with. (existing demo instances don't allow adding/managing projects) ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Translating notifications raised by mailman-core in postorius
Hi, Currently Postorius handles form submissions like this: 1. Check to see if inputs are malformed, raise error if so 2. Submit to mailman-core and see what the response is. - ConnectionError: Mailman-core is unreachable, display error message - Success: Display some success notification - HttpError: This happens when mailman-core rejects the request for some reason. Currently the HttpErrors are passed without modification to the user in a notification. Postorius should have some way of translating these. We can't translate the raw messages because they sometimes contain specific strings like emails and it would require us to manually add the strings to the .pot files. Theoretically the core could translate the messages before passing them to postorius. This would require core to know about the language it should translate to. I don't think this is a very good approach because we would have to make sure we offer the same languages for core and postorius and I'm not sure how we would pass the languages to core... I propose core to return an error code with each request. That way postorius can add strings for all the errors that it cares about and translate them accordingly. This would require an api change. Since 3.1 would change the api anyway, it would be nice to include the changes there. What do you think of my proposal? Do you have a better idea? The specifics have to be worked out of course. Simon ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
