Getting iNaturalist.org registered on translatewiki

Welcome! As Reedy told you we support YAML so that's fine. Some notes.

  1. We don't support es-MX and other sublocales (yet), is that a dealbreaker? By default "en" is "en-US" for us, but perhaps we can switch the meaning in import/export from your repo.
  2. We need message documentation for each string you have in your en.yml. You can create a qqq.yml as if you were translating to such a locale. (Assigning to you until this is done.)
  3. For plural, are you using rails-i18n rules as OSM? Translators will need to know as well.
Nemo (talk)18:23, 4 December 2014

Thanks Nemo:

1. Does translatewiki have other suggestions for how to deal with expressing differences in American English vs UK English, or Mexican Spanish vs Spain Spanish, etc?

2. we'll commit a message documentation qqq.yml file now

3. we're investigating how OSM handles plurals, but we are using basic built-in i18n rules, as can be seen toward the top of the en.yml file https://github.com/inaturalist/inaturalist/blob/master/config/locales/en.yml - is that no longer standard?

Loarie (talk)18:47, 4 December 2014
  1. We do have some sublocales here, e.g. en-gb. We tend to advise against them because usually they get dusty, but if you have an active translator base adding them shouldn't be a big deal AFAIK.
  2. Ok.
  3. I've not looked into what you're doing now, but we recommend/require using some standard system, usually backed by CLDR data. rails-i18n looks quite common.
Nemo (talk)18:55, 4 December 2014

1. since iNat is being localized nationally, e.g. http://naturalista.conabio.gob.mx/ & http://naturewatch.org.nz/ the sublocal thing comes up alot, but the good news is we do have active translator bases behind each national localization

2. Here's an initial commit of the message documentation file https://github.com/inaturalist/inaturalist/blob/master/config/locales/qqq.yml

3. OK - will look into this more...

Loarie (talk)19:27, 4 December 2014

Nemo:

1. The only sublocales we currently support are: en-US, es-ES, es-MX if that looks good can we close this issue (1)? (will we be able to add additional locals - i.e. yml files - once iNat is registered or is that a bottleneck?)

2. We'll continue to flesh out qqq.yml https://github.com/inaturalist/inaturalist/blob/master/config/locales/qqq.yml to annotate confusing or ambuguous terms, but is it really necessary for us to annotate every string? I've looked at some other examples of this file on translatewiki projects (e.g. https://github.com/EOL/eol/blob/master/config/translations/qqq.yml) and it doesn't look like annotating every string is the usual practice. If our qqq.yml looks like a good start can we close this issue (2)?

3. I now have a better understanding of rails-i18n pluralization which is what we're using since its built into rails. You mentioned that this plulralization was not convincing: https://github.com/inaturalist/inaturalist/blob/master/config/locales/en.yml#L39 Is that because you'd prefer it to be like:

x_observations:
   one: "%{count} observation"
   other: "%{count} observations"

(e.g. https://github.com/openstreetmap/openstreetmap-website/blob/master/config/locales/en.yml#L1268) Because looking at other translatewiki projects, it looks like our existing syntax is used: https://github.com/EOL/eol/blob/master/config/translations/en.yml#L131 If our pluralization system looks good, can we close this issue (3)?

Any other issues we need to address?

Thanks!

Loarie (talk)22:53, 5 December 2014
  1. IMHO that's fine enough.
  2. Having docs for 100 % of the strings is the policy applied by the most careful projects, like MediaWiki. That said, we find that the minimum is to document all parameters (like %{omniauth}): you have about 500, if I see correctly? This is important because, even if it may look obvious to you from the parameter name, translators need to know whether it's a noun vs. proper noun and so on.
  3. Sure, this syntax is a bit verbose but it's fine to follow the language's standard.
Nemo (talk)23:12, 5 December 2014

Got it, thanks.

We'll update the qqq.yml file to at least document all the parameters.

Will things be more or less in order after that?

Loarie (talk)03:53, 6 December 2014

Nemo - We've now documented all parameters in the qqq.yml https://github.com/inaturalist/inaturalist/blob/master/config/locales/qqq.yml

Are there any remaining issues? If not, what are next steps?

Thanks!

Loarie (talk)00:12, 11 December 2014

This looks like a nice project that is a good fit for translatewiki.net. We (Nikerabbit, Siebrand) will need commit access to push translations. We can start setting up the project here to see if any further issues appear.

Nike (talk)14:53, 15 December 2014

Thanks Nike: Is it possible to rather commit to a fork and issue pull requests? That would be preferable for us. Thanks for setting up the project - let us know if you run into any problems.

Loarie (talk)01:12, 16 December 2014

No, we don't support pull requests. Review must happen on wiki, otherwise it makes little sense to use a wiki.

Nemo (talk)07:09, 16 December 2014

Nemo, would you be able to push translations to a branch other than master?

Loarie (talk)18:18, 16 December 2014

Nemo, regarding the pull request/separate branch request, we understand that the translatewiki review process is wiki-based and that's fine. Our motive is not for us to review the translations (we can't, since we don't speak the languages) but to review the effect of the translations on the code e.g. things like Nike mentioned below in 3 & 4

Loarie (talk)19:22, 16 December 2014
 
 
 

Some more questions notes:

  1. What is the difference between "es" and "es-ES" locales?
  2. There are what we call lego sentences in the strings: output is constructed by concatenating stuff in the code. This is bad for languages with different word order.
  3. It looks like most of your strings allow arbitrary HTML. While we have never had malicious HTML inserted by our translators, it's still a risk you could avoid by escaping output. By far more likely is that translators will create invalid HTML by mistake.
  4. Worth checking if the date_picker module has upstream translations you could use instead of re-translating them here. There are also strings which are directly input to JavaScript. If a translator makes mistake there, JavaScript on your site might not run.
  5. Do you have a (preferably SVG) logo?

Example of lego:

  for_a_widget_showing_recent_observations_from: For a widget showing recent observations from %{place_name}, check out the
  for_more_information: for more information.

Example of possible lego or a word which is impossible to translate without message documentation:

From
Nike (talk)15:52, 16 December 2014

1. es is general Spanish and es-ES is Spanish particular to Spain.

2. We'll work on reducing lego sentences

3. We're concerned about that too and want to make sure we test this stuff on a branch before integrating (see request above re: commit access) We'll just have to watch and maybe try using raw() if it'll be a problem

4. We'll check out what the module has. Can you point us in the right direction with a link?

5. Here's two versions of the logo in SVG format: https://www.dropbox.com/s/qhhwfgkbxye0lvm/logo.svg?dl=0 https://www.dropbox.com/s/4zf0t45jkaqo5ko/bird-square-text.svg?dl=0

Loarie (talk)19:20, 16 December 2014

Hi, sorry for the wait, but it's hard for me to motivate our staff to work on this project when we can't ensure the translations will be used: I recommend that you give push access to siebrand and nikerabbit. Before his message Nike had already prepared most of the config on dev.translatewiki.net, so it really takes little more to get started.

  1. The differences between the two files are not clear, they are mostly duplicative. Here "es-ES" happens under "es" (and pt-PT on "pt", fr-FR on "fr" etc.), so I guess we'll pull and update "es" <-> "es". It's not clear to me how your "es-ES" file was generated, but if we don't export to it you can continue working on it in the same way. Is this ok?
  2. Ok.
  3. See above. In general, no matter what system you use, translators should translate, not worry about programming languages. So it's extremely recommended that you don't rely on translators being (or being assisted by) programmers for their translations.
  4. It's advisable to know what upstream software you're working with. It seems it might be [1] but I have no time to inspect your source code.
  5. Ok, uploaded at File:INaturalist_logo.svg.
Nemo (talk)11:09, 22 December 2014

Hi Nemo, Thanks to you and Nikerabbit for the discussion on freenode yesterday. Nikerabbit & Siebrand now have commit access and sounds like every thing is sorted on our end and now Nikerabbit just needs a few free hours on his end go get this project rolling. We'll eagerly await hearing from you guys when things are set up, but if in the meantime you need anything from us, please give me a shout here. -Thanks!

Loarie (talk)21:43, 31 December 2014