
I'm certainly happy to see somebody interested in working on this! However, I have some questions about exactly what the development strategy should be (see my comment on #67). We should talk about it on this list so everybody sees it, then move to #67 (or wherever) when the strategic issues are clear.
Are you thinking about doing this for GSoC? If so, we all need to talk about this and get it nailed down. This kind of thing can be a real hairball, something that you don't want to do "on deadline". I don't want to scare you away, it could be quite straightforward, too. But let's start talking now. Again, if GSoC, I'm quite unclear on where the "code" (GSoC only supports coding projects) comes in. Could be I'm just blind :-) but let's nail that one down too.

No it wasn't for GSoC, i just wanted to do something in opensource and this issue caught my attention as it was labelled as "beginner friendly" . I went through the links attached and felt that i can do this.
On Tue, Mar 1, 2016 at 2:13 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
I'm certainly happy to see somebody interested in working on this! However, I have some questions about exactly what the development strategy should be (see my comment on #67). We should talk about it on this list so everybody sees it, then move to #67 (or wherever) when the strategic issues are clear.
Are you thinking about doing this for GSoC? If so, we all need to talk about this and get it nailed down. This kind of thing can be a real hairball, something that you don't want to do "on deadline". I don't want to scare you away, it could be quite straightforward, too. But let's start talking now. Again, if GSoC, I'm quite unclear on where the "code" (GSoC only supports coding projects) comes in. Could be I'm just blind :-) but let's nail that one down too.

On Mar 01, 2016, at 11:13 PM, Stephen J. Turnbull wrote:
I'm certainly happy to see somebody interested in working on this! However, I have some questions about exactly what the development strategy should be (see my comment on #67). We should talk about it on this list so everybody sees it, then move to #67 (or wherever) when the strategic issues are clear.
I added a comment in #67.
The core has a bunch of templates that need translation, although it's unclear whether a gettext approach will help. Probably we can just accept merge requests for translated templates.
The core also has some translatable strings, mostly for substitutions into fields that it creates out of whole cloth. For those, gettext-extraction and translation techniques will be helpful.
I'm happy to continue discussing both of the above in #67.
It's true that the bulk of the translation work project-wide will be for Postorius and Hyperkitty. Both of those are Django projects, and I'm sure Django has i18n support, although I really don't know much about those details. To the extent that all subprojects can share infrastructure, great, but that shouldn't come as a sacrifice for Django's natural i18n workflow. Aurelien and Florian should probably describe how they want it to work for those two projects.
Cheers, -Barry

Barry Warsaw writes:
It's true that the bulk of the translation work project-wide will be for Postorius and Hyperkitty. Both of those are Django projects, and I'm sure Django has i18n support, although I really don't know much about those details.
The OP is already aware of Django's I18N, so I think we're off to a good start there.
To the extent that all subprojects can share infrastructure, great, but that shouldn't come as a sacrifice for Django's natural i18n workflow. Aurelien and Florian should probably describe how they want it to work for those two projects.
Agreed. I think the main Django I18N frameworks end up producing potfiles, so the translators should not have too much new infrastructure to learn.
Steve
participants (3)
-
Barry Warsaw
-
Saurav Kumar
-
Stephen J. Turnbull