Primary guidance pages for setup: https://translatewiki.net/wiki/Translating:New_project and https://translatewiki.net/wiki/Setup_of_a_new_project

We'll need to apply a license to the TWLight project before we can get started. Based off all of our communication, GPLv2 seems like an obvious choice, but I wanted to check in before a applying a license to the app.

I think we did this with Andromeda already and chose MIT. Let me check...

@Ocaasi Yeah, MIT is also a fine and dandy open license. If there's already been a decision made there, I'm happy to apply it to the project repo.

@Ocaasi Just a reminder that this is something we'll need before we start the translatewiki application process. I'm still working on other bits of this as well, so it's not blocking progress yet.

Ok, let's use MIT:

https://opensource.org/licenses/MIT

(Unless you have a strong feeling or preference for GPLv2. Either is "free enough", and I think it's a matter of philosophy at this point.)

https://opensource.org/licenses/GPL-2.0

It's interesting that this is basically a share-alike debate just in code not wikitext.

While troubleshooting another issue, I've removed all compiled translations from the code base and cleaned up the code where needed so we can complete compilation of translations. We're now compiling translations upon code deployment, which is a prerequisite for pulling updates from wiki translate automatically.

I've applied the MIT license and created the translation documentation file in the reserved qqq namespace. I invited the translatewiki github account to be a contributor with write access on our github repo for the project. I reached out to the translation folks via irq about getting this fired up. I'll post updates here as I get them.

I'll need to add contextual notes for every message string that is up for translation.

Ouch. Something that me or Nikki could do?

Trying to find out more detailed info from the folks on irc. It's a little problematic since the channel doesn't allow public logging; I basically have to try to keep a connection to irc up to wait for a response to my questions, which can have quite a delay . If my computer goes to sleep, I just miss what's happening in the channel.

So, this could be a @Samwalton9 or @Nikkimaria task, at least partially.
So if you take a look at:
https://github.com/WikipediaLibrary/TWLight/blob/master/locale/qqq/LC_MESSAGES/django.po
You'll see that line 28 has a translator note on it. We need to add translation notes in there for every message. The notes get into that file by being picked up in the bit of code referenced in the comment. eg.

#. Translators: This labels a section of a form where we ask users to enter info (like country of residence) when applying for resource access.
#: TWLight/applications/forms.py:189
msgid "About you"
msgstr ""

There's a tranlator note in TWLight/applications/forms.py just ahead of the message label on line 189, that our tooling was able to pick up and place in this document. We'll need to add useful translation notes as Translators: comments in the source code. Basically, you'd need to fork the codebase on github, and start backtracing the referenced code bits in django.po and adding comments.

feel free to decline any or all of this task.

Happy to do this - will work on it this week.

We've got Sam's translator comments integrated into the codebase, and the next step is for me to regenerate the translation files, including the one for the reserved qqq namespace.

@Samwalton9, you reference a file of leftover bits in the pull request, but the link in the pr is broken. Is that something you attach here or send via email?

I've regenerated the translation files with what I have so far.

@Samwalton9 Hey Sam, the link you put in the pull request for translation questions/problems you had didn't open. Can you resend the link to Jason?

Can you try the link again, making sure it's opening in a text editor? I just downloaded it on my phone no problem.

Yeah, it's a strange, but consistent issue. See screenshot:

Ah, the link is a signed url to an amazon s3 bucket. The signature check uses cross-site scripting, which I have purposefully broken for myself in a few different ways. Apparently nobody has tried to send me a file via this mechanism on github before. I opened it in a browser configured with two standard deviations less paranoia, and voilà I have your data. Sorry to have introduced a complication on this one.

official request submitted to translatewiki.

Better link.

Is anybody working on this?

Is this stuck anywhere?

We had to prioritise a few other areas of development over the past months, but are aiming to get back to this during March.

With the taggit changes as part of this, we may or may not also fix T171841.

This should be good to go, just waiting for final confirmation and setup from Translatewiki.

https://github.com/WikipediaLibrary/TWLight/blob/master/locale/en/LC_MESSAGES/django.po

It's ok to follow the Django format, which is shared by several other projects. It would be good to clarify whether you have any support for grammatical gender or plural: translators will have questions and suggestions when they encounter some message which can't be translated correctly (for instance those which may depend

Several source strings can be improved. A couple examples follow.

• I see that many messages have a bizarre amount of markup, including newlines or <p> tags (with no apparent pattern), initial and traling space, hardcoded links. We recommend to split multiline strings into separate messages, so that the markup doesn't become the translators' responsibility: otherwise you increase the chance of mistakes and later changes to the source text.
• Installation-specific strings such as the URL https://en.wikipedia.org/wiki/Wikipedia:The_Wikipedia_Library/Coordinators/Signup are expected to become variables passed to the message (and probably defined in the software's configuration rather than hardcoded), for the string extraction to be considered complete.
• Inconsistencies in style could confuse translators. For instance, I see both This Partner is not available and This partner is now waitlisted: you probably want a consistent lowercase here.

Such changes to the source strings are better fixed immediately, rather than later, to avoid wasting translators' time. With Gettext this is especially important because every small change to the source text will create a new message and (by default) lose all translations.

The file for qqq has been created https://github.com/WikipediaLibrary/TWLight/blob/master/locale/qqq/LC_MESSAGES/django.po but all strings are empty. Translate's system for Gettext will get the code comments from the source file and deliver them to translators anyway, but a file with empty strings may be confusing. There is also no need to prefix all comments with "Translators: ". I see several possibly unclear terms (like "slug") are not accompanied by message documentation. None of these is a deal breaker, but we'd expect improvements from you after the translations start flowing.

Thanks for the suggestions @Nemo_bis! I'm going to do a run through all our strings and translation comments and see if I can improve them per your advice.

There is also no need to prefix all comments with "Translators: ".

The "Translators:" prefix is how django determines which comments are supposed to be added to the translation files, so as far as I know we can't change this.

many messages have a bizarre amount of markup, including newlines or <p> tags (with no apparent pattern), initial and traling space

For the record, it looks like some of the strangest looking cases of this were a result of many {% blocktrans %} not being {% blocktrans trimmed %}.

Did a first pass fixing the blocktrans issues and adding some missing translation strings.