Spanish

[Intimaria]

Context

• Fixes Translations for REFUGE RESTROOMS #396 for Spanish Translation

Summary of Changes

• I accidentally closed Spanish translation  #413 so am starting a new PR
• Adds es folder with translations

Checklist

• Tested Mobile Responsiveness
• Added Unit Tests
• CI Passes
• Deploys to Heroku on test Correctly (Maintainers will handle)
• Added Documentation (Service and Code when required)

[Intimaria]

Arr. I forgot to include the text_msg.yml translation. Committing asap.

[DeeDeeG]

This is looking good. (Not to say I can read it so far as to understand it 100%, so we're still working on reviewing the actual translations! And sorry for the delay.)

Just a small thing: There is a third commit here that adds English lines back into text_msg.yml: 6f209e6

If you can delete that and push again to your branch, that would be great. 👍 (Let us know if you want a hint as to how to do so.)

[Intimaria]

Hi, thanks! Done.
Thanks for noticing that, I hadn't realized that last merge had reverted the changes.

I found a revert option for the merge by searching online and it seems to have passed the checks.

This is looking good. (Not to say I can read it so far as to understand it 100%, so we're still working on reviewing the actual translations! And sorry for the delay.)

I have asked around for reviewers. Perhaps, Antu said they will try to take a look if they have the time. I will continue to ask around in the meantime.

[mi-wood]

I'll spend some time today looking for someone to review this. Thanks for sticking with it!

[DeeDeeG]

Just as a heads-up: My work to update the remainder of the app's English phrases to be translatable seems to be almost done.

That is Pull Request #421.

When that merges into develop, there will be new phrases to translate. (Sorry! But that also means the whole app will be translatable, not just bits and pieces of the app.) Some of the new phrases will be in additional en.yml files, whereas some phrases will be added to existing .en.yml files.

This project has involved a lot of shaking up of the app in order to get ready for translations. Sorry for the complications, and yes indeed, thank you for staying with it.

[Intimaria]

Just as a heads-up: My work to update the remainder of the app's English phrases to be translatable seems to be almost done.

Great! When that gets merged I'll pull it in and start translating them. From what I can see the text in those files is smaller bits of text distributed around perhaps, rather than large chunks of text. As far as I can tell, the most visible will be the front page, and the forms, buttons, nav etc. But will be mainly little bits of text here and there. So it shouldn't take long.

Perhaps there, it's just getting the commits and things right. I know I can ask for help and you are all very helpful! We can do this!

A couple of questions along the same lines of the upcoming translations, is about the name. I have left the name untranslated as it is seemed to me at the time it would be better for it to be site wide REFUGE and have a certain kind of brand recognition despite language differences (a bit like uber or whatever, which everyone knows what it stands for now in terms of the app, despite it being a german word), but it would be good to know if the consensus would be to have it translated into local language (in Spanish it is Refugio, so not too different, but not sure about other countries). I guess I thought if someone comes accross it in an article they would probably search for it in the name it is most well known for. But I'm not sure.

If there's a big push to translate the name to a locally understandable one (I mean it's not too different), I'm happy to roll out those changes when the next set of translations come in through the #421 PR merge!

[DeeDeeG]

A couple of questions along the same lines of the upcoming translations, is about the name.

This is an interesting question to me, too. I left the text "Refuge Restrooms" in the nav bar untraslatable, since I expected we wanted that unified naming and Proper Noun treatment, where it doesn't get translated.

There are three ways I can think of to do it:

• Full localization
• Translate "Restrooms", but leave "Refuge" untranslated.
• No translation whatsoever.

If I had to have an opinion on the matter, I would presume to not translate the name.

[Intimaria]

Yes, I agree with having refuge as it is the “known name”, and whatever is decided I’m happy to add to the translations.
I think it is helpful to translate restrooms perhaps as it is not a common word or easy to guess and not necessarily the key part of brand recognition - again am happy to make these changes when the PR is merged.
If you think it may be helpful, I may pull from your repo @DeeDeeG and start on the bits that are done. But again, I’m not sure if this is a good way to go about things or will make things messier later.

[DeeDeeG]

If you think it may be helpful, I may pull from your repo @DeeDeeG and start on the bits that are done. But again, I’m not sure if this is a good way to go about things or will make things messier later.

Short answer: Go for it!

---

Long answer (feel free to ignore if this info is not helpful!):

Firstly, I think the files in #421 are mostly final. So I would say, go for it. (I still might get some comments on it asking for changes, but I feel like it's around 95% final, if not 100%.)

You probably don't need or want the commits of PR #421 in this branch, so any way you get the files, I would recommend putting translated versions in config/locales/es/ and commit the translated versions to this branch. (Also don't need to add the new English files here.)

As mentioned in an edit to one of my comments at some point (not surprised if no-one saw the edit!) I mentioned we probably won't have any merge conflicts (for Spanish branch merged into develop branch, i.e. this PR) past this point. I don't think other PRs are going to alter the config/locales/es sub-folder, which would mean there is zero chance for merge conflicts. In other words, your branch will work regardless of what happens with upstream, for the time being. No need to sync commits up any particular way.

Also, if Travis CI tests for this PR end up failing, that's fine. It wouldn't necessarily mean anything is wrong with this PR, and we could either ignore it or work around it if need be. There are other ways to confirm the files here are correct in that situation.

[DeeDeeG]

If you do want to try the translations locally, I would suggest making a new branch off of upstream's new-translation-ready, and merging your Spanish branch into it.

[Edit: Or branch off of your Spanish branch and then merge upsteam's new-translation-ready in, either way has the same result.]

You could then change this line in config/application.rb to add the es locale:
https://github.com/RefugeRestrooms/refugerestrooms/blob/develop/config/application.rb#L26

And then the page will show you the Spanish translations. (Assuming your web browser is configured to prefer the es locale before en.)

(I assume you would want to do this yourself for learning purposes. If not, I basically did the same thing here: https://github.com/DeeDeeG/refugerestrooms/tree/Spanish-plus-rebased-translation-ready)

[Intimaria]

ahhh! Thank you @DeeDeeG, for all your detailed explanations, I will do all of that as soon as I can!

[Intimaria]

Hi sorry about delays, I haven't disappeared, just had a lot of work over the last few days. I'm still on it!

[DeeDeeG]

Hi again,

Thank you for the update. (And no worries, we all get busy with outside things from time to time. Or more like all the time, heh, but yeah, we are all balancing a few things.) We'll be happy to see your contributions whenever you get the time.

---

On another subject, @tkwidmer, @mi-wood, do you have some thoughts on how/whether to translate "REFUGE Restrooms"?

I think we can do one of these three:

• translate the whole phrase, "refuge restrooms" into each language
• don't translate "Refuge", translate just "restrooms"
• translate neither, leave it "REFUGE Restrooms" regardless of language

Thinking forward, this might have impact on brand names such as REFUGE Housing, for example. Do we translate "housing" there? Do we translate both words? Neither?

(See this comment and the two subsequent comments for discussion so far.)

[Intimaria]

Hi @DeeDeeG thanks for understanding! To save time I cloned your translation ready branch into my local repo. I want to merge your changes into my Spanish branch, would I checkout Spanish and merge my version of Spanish-plus-rebased-translation-ready, or checkout my version of Spanish-plus-rebased-translation-ready and merge Spanish so I don't lose any of your changes? I have a feeling it's the former, but I don't quite understand merges yet and I really want to! I can then merge the new revisions that are in #430 ! And finally I will translate the files you added once everything is merged into my local Spanish so I can push to it's remote & it appears in this PR. Does that sound about right? Is there anything I should be aware of?

[DeeDeeG]

Hi. There is a simple answer to this, which is: I think merging the latest upstream develop into Spanish will work well and be the best path forward at the moment. #421 just got merged into develop, finally. I'll get to that near the bottom of this comment, but just to make sure to get the most out of this as a learning opportunity, I'll answer all the questions as well.

To save time I cloned your translation ready branch into my local repo. I want to merge your changes into my Spanish branch, would I checkout Spanish and merge my version of Spanish-plus-rebased-translation-ready, or checkout my version of Spanish-plus-rebased-translation-ready and merge Spanish so I don't lose any of your changes? I have a feeling it's the former, . . .

Yeah, I agree that some-other-branch into -> Spanish is pretty much the way to go.

I can then merge the new revisions that are in #430 !

Great! 🎉

And finally I will translate the files you added once everything is merged into my local Spanish so I can push to it's remote & it appears in this PR.

Awesome.

Does that sound about right?

Yeah, pretty much. 👍 In principle that all makes sense. But there is a new piece of information you might wish to have before proceeding that way.

Is there anything I should be aware of?

Well, here's the thing. The PR #421 just got merged into upstream develop, finally. So you may just want to fetch the latest from upstream, and then merge develop into -> Spanish

I made a big explainer post about merges below; I do hope it will be helpful without taking overly long to read through. (Much of it isn't relevant to this PR, since you probably won't run into merge conflicts; A lot of the post below is about merge conflicts.)

[DeeDeeG]

but I don't quite understand merges yet and I really want to!

I hope this explanation of merges will be helpful!

---

Where commits end up when you merge

Merging on the command line merges all branches you type after "git merge" into the current branch...

Working on branch C.

git merge A B

Results in: A and B merge into -> C

---

Working on branch A:

git merge B

Results in: B merge into -> A

---

You get, at minimum, every commit from both/all the branches involved in the merge, submitted into the target branch (which is always the current branch). (You may also get a "merge commit" in the target branch, depending on the complexity of the merge.)

Merging any two branches in either direction (merging A into B, vs. B into A) is pretty much equivalent, in terms of the changes to files. It is only different with regard to what branch everything gets combined into. For this PR, I expect you will want to merge stuff into Spanish from other branches, so that Spanish contains all the changes, especially since Spanish is the one that eventually needs to be pushed to GitHub for this PR to get updates.

---

Under-the-hood details about merges

(Stuff that Git does to resolve a merge)

Git usually picks a merge strategy for you when you do a git merge

Fast-Forward merge strategy (So simple, this arguably isn't a "true merge")

The simplest is a fast-forward. Say you are on one branch A, then branch off to another branch B, and do some commits. B is now "Ahead of" A by however many commits. There is only one way to go from point A to point B, which is "forward". Merging B into A at this point will be done with the "fast-forward" strategy, where branch A adds everything from branch B, and the two branches become identical.*

*(identical other than having two different branch names, A and B, respectively).

(Fun fact: This style of "merge" happens when you run git pull on an upstream-tracking branch and your local copy is simply out-of-date compared to upstream. So, your local copy gets "fast-forwarded" to match upstream.)

Every other merge strategy

The rest of the strategies are just variations on a theme: Any of them tries to figure out what actually differs between the branches, and tries to put all the commits from the source branch(es) into the target branch, and fails if anything too crazy happens to any particular file during the merge.

Simple merges with no conflicts (no-fast-forward)

Say you are on A and you branch off onto a new branch B. You do a bunch of commits on B dealing with some-file.txt. Then you check out A again, and do another commit on A altering some-file.txt. Now we try to merge branch B into A. If the changes to some-file.txt are on different lines of the file, git should be smart enough to piece all the changes together automatically. It will then ask you to write a message for the merge commit, and when you finish doing so, the changes from B are successfully merged into A.

Merges with conflicts

Maybe you branched B off from A, and did commits on both branches, like above. But one line of some-file.txt is updated in two different ways, one on A branch and one on B branch. When you try to merge B into A, git will complain that there is an ambiguous situation for merging, that it has given up, and you need to go in and solve the problem yourself. (How helpful! :P) The error message looks like this:

Auto-merging some-file.txt
CONFLICT (content): Merge conflict in some-file.txt
Automatic merge failed; fix conflicts and then commit the result.

Fixing merge conflicts

At that point, you may see something like this in some-file.txt:

Hello!

<<<<<<< HEAD
Merging with Git is complex.
||||||| merged common ancestors
Merging with Git is complicated.
=======
Merging with Git is super easy sometimes, but sometimes there are merge conflicts
>>>>>>> B

That means there are three versions of that one line of the file (some-file.txt).

• between <<<<<<< HEAD and ||||||| is the version in your current branch (A).
• between ||||||| merged common ancestors and ======= is the same line of the same file as it appeared at at some point in an earlier commit, specifically a commit that is present on both branches if you look far enough back.
• between ======= and >>>>>>> B Is the version on branch B

Git expects you to go in and edit the files (by hand) that have conflicts, then once you're done fixing the files up, git add and git commit them.

I personally find all the <<< ||| === >>> symbols a bit confusing. So I use Atom
Which gives me a nice interface to pick between the different changed versions.

I usually click Use me on one of the suggested versions in Atom, type any additional changes to the file if I need to, then save the file with Ctrl + S, then stage that changed version by double-clicking the file in the Git sidebar of Atom... and quit Atom so I can do the rest on the command line. You can actually finish editing the file, stage the changes, and commit, all from Atom. I'm just very fond of the command-line, so I do as much there as possible. You can do it with whatever tool/method you like.

Summary

Merging is (sort of?) a simple process, unless there there are merge conflicts. If you know how to resolve merge conflicts, even complicated merges are possible. It's not very intuitive at first, but hopefully makes sense eventually.

P.S.: I recommend taking another look at this section of Think-Like-(a)-Git if you want a more step-by-step, hands-on lesson: http://think-like-a-git.net/sections/testing-out-merges.html

P.P.S.: Similar to Atom, there is GitHub Desktop. GitHub Desktop probably helps you resolve merge conflicts just as well as Atom, but I haven't used it much. They don't make a version of it for Linux. 🤷

[Edit: GitHub Desktop doesn't help resolve merge conflicts, from what I can tell. Can't confirm without a machine to test it on; I might try it on Windows soon. For now, Atom is the best way I know to fix merge conflicts.]

[jojoalienigena]

Hola, la pagina de Refuge en Twitter me mandó a colaborar en la traducción y francamente si veo muchos detalles pequeños en la traducción, sobretodo en la terminología LGBTQIA y uno que otro detalle en las tildes. Un ejemplo es que no es intersex, sino intersexo o intersexuado y en la traducción de gender noncomforming debería de ser de género no conforme.

[DeeDeeG]

For the record, the tweet @jojoalienigena is referring to is this tweet here:
https://twitter.com/REFUGErestrooms/status/953738797606408193

For our English speaking maintainers...

This is the comment above, rendered into English with Google Translate, then filtered through my attempts to improve over Google Translate's translation (see [brackets] for my edits)...

Hello, the Refuge page on Twitter sent me to collaborate in the translation and frankly [yes] I see many small details in the translation, especially in the LGBTQIA terminology and one or another detail in the accents. An example is that it is not ["intersex"] but ["intersexo"] or ["intersexuado"] and in the translation of gender noncomforming it should be ["género no conforme"].

Sorry I am not fluent in Spanish. I will post a version of my comment translated with Google Translate below.

[Edit: Whoops, wrong twitter link! Fixed.]

---

Para que todos lo sepan, el tweet @jojoalienigena se refiere a este tweet aquí:
https://twitter.com/REFUGErestrooms/status/953738797606408193

Para nuestros mantenedores de habla inglesa ...

Este es el comentario anterior, traducido al inglés con Google Translate, luego filtrado a través de mis intentos de mejorar la traducción de Google Translate (ver [corchetes] para mis ediciones) ...

Hello, the Refuge page on Twitter sent me to collaborate in the translation and frankly [yes] I see many small details in the translation, especially in the LGBTQIA terminology and one or another detail in the accents. An example is that it is not ["intersex"] but ["intersexo"] or ["intersexuado"] and in the translation of gender noncomforming it should be ["género no conforme"].

Lo siento, no soy fluido en español. Esta es una versión de mi comentario (escrito en inglés) traducido con Google Translate.

[Edición: ¡Ups! Enlace incorrecto de twitter. Arreglado.]

[Intimaria]

Hey! great! It would be fantastic to get your corrections @jojoalienigena. Realmente sería genial tener tus aportes, gracias!
En argentina usamos intersex y varios terminos para referirnos a personas no binarias, el más común es el gender-fluid, tendemos a usar mucha terminología inglesa y por ende a veces no siempre es lo mejor. Sería genial recibir tus correciones.

[Intimaria]

Also, there are some previous corrections which addressed the missing tildes! The previous corrections are in #430 and are really great & worth checking out! Maybe we can incorporate intersexo and genero no conforme into the changes made in that PR? Are there are other issues with terminology you see?
Avisame si prefieres que escriba en español.
Gracias nuevamente!

[mi-wood]

I think the internal double quotes are throwing off the test. Those need to be escaped.

[DeeDeeG]

I'm glad to know what was causing these errors.

BTW I don't think we use these strings anymore, so the file can just be deleted. I already deleted it in locales/en, so I think we probably want it deleted here, too.

[DeeDeeG]

I think you can use single quotes (') wrapping the outside of the whole translation, then use double quotes (") within the translation string.

[DeeDeeG]

By the way, I asked around, and it seems like we are leaning pretty strongly toward not translating the phrase "REFUGE Restrooms", treating it as the shared brand name across localizations/translations.

[DeeDeeG]

Now that this has seen comment/review from two other people who are fluent in Spanish, I'm pretty confident it's a fine translation. If there are any more improvements that can be made, that no-one noticed yet, those improvements can still be made if/as needed, on an ongoing basis. In any case, I think it's nicer to get this out to the users, rather than spending more time trying to make this PR perfect.

Nothing in the app is at the level of perfection anyway; it's just at the level of "the best we can do."

Thanks again for your work here. I think it will mean a lot to Spanish readers/speakers who want to use the site.

(Not sure if this translates the iOS/Android apps too, but I think that would have to be done separately if we want to do that? cc @hkellaway, @hissingpanda)

---

I looked through the commits here and made a simplified version of this branch, here: develop...DeeDeeG:simplified-Spanish

I think making the Git commit history look something like that would be the best way to structure this PR's commits before merging. (I can handle such details, if you like, or can let you handle it. Whatever works is fine. Ultimately, the important thing is getting the finished translation available to users, IMO.)

Let us know if you need anything, or have any questions/comments/updates about stuff.

[tkwidmer]

This would only translate viewing the web from IOS. The iOS app is its own beast with native code.

Although at some point it might be worth build a react app, that can serve react native and the web.

[tkwidmer]

It looks like the build is failing though.

[DeeDeeG]

It's the thing @mi-wood mentioned in the code review/comment thingy.

Travis log line 1337 has the full error:

I18n::InvalidLocaleData:
  can not load translations from /home/travis/build/RefugeRestrooms/refugerestrooms/config/locales/es/landing.es.yml: #<Psych::SyntaxError: (/home/travis/build/RefugeRestrooms/refugerestrooms/config/locales/es/landing.es.yml): did not find expected key while parsing a block mapping at line 3 column 5>

We can either fix the quote styles, or else just delete the file, like we did in the English (en) locale.

[mi-wood]

I'm cool with going ahead and removing that file and merging this

[DeeDeeG]

Just for the record, I don't think @jojoalienigena's comments were addressed yet, since there was some attempt at ongoing dialog. But we haven't heard back so far, so I don't think we're going to. I think it would be easy to do a simple PR addressing that comment after this is merged, if needed.

[Intimaria]

Hi! Please can we wait until the weekend to merge so I can address a bunch of the things. I want to

• remove problem file.
• add @jojoalienigena’s proposals
• translate those added pages by @DeeDeeG
• simplify commits
  But I can only really get to it on the weekend. It would be great to get those things tied up neatly

[DeeDeeG]

​@Intimaria thank you for translating all the new files!

[Intimaria]

Hi, @DeeDeeG! I'm glad to!
I'm now just searching through all the old posts to see how to clean up this branch's commits so we can merge... 💃

[mi-wood]

This is deployed at https://refuge-staging-14.herokuapp.com/about

I set my browser language to Spanish, but still can't see the translation. Can someone else check this and see it I just haven't set it right?

[mi-wood]

language header is set in the request

[mi-wood]

Updated this: https://github.com/RefugeRestrooms/refugerestrooms/blob/develop/config/application.rb#L26 👍

[mi-wood]

I think the about page might have changed from when this PR was originally created. This now has multiple sections and is displaying English since it doesn't match: https://github.com/RefugeRestrooms/refugerestrooms/blob/develop/config/locales/en/about.en.yml#L6

[mi-wood]

@DeeDeeG @Intimaria did either of you look at translating forms? It looks like they're still coming up in English for me. I'm getting too tired to look, but I imagine simple form is inferring it from variables

[Intimaria]

Thanks @mi-wood, you're right!
(EDIT: wow. It's so exciting to see the Spanish come up. Hopefully the translation I sent below will be enough to correct this.)
I missed those changes in p1header in the about section, am not sure how to add that now that it's merged, I can add the translations here if anyone wants to add them directly
English:
second: 'We’re trans led and seek to create a community focused not only on finding existing safe restroom access, but also advocating for transgender, intersex, and gender nonconforming people’s safety.'
Spanish:
second: Estamos dirigidos por personas trans, y buscamos crear una comunidad centrada no solo en encontrar un acceso seguro a los baños, sino también en abogar por la seguridad de las personas transexuales, intersexo y género no conformes.
Re, forms:
Oh dear, I focused on the files in config/locales, as I was not sure about other possibilities, but I would be happy to take a look at translations for the forms and any other bits where necessary, in whichever way is easiest.

• The add restroom form has some translations (the text inside the forms + the send buttons). Name, city and country, needs translation. I'm looking at the file, https://github.com/RefugeRestrooms/refugerestrooms/blob/develop/config/locales/es/restroom.es.yml
  'Name' is translated but isn't showing up as such, there's a comment which says

# only overridden attributes here, defaults work as expected
# (e.g. database field 'city' will be appear as 'City')

• The contact form has no translations yet. The translations in https://github.com/RefugeRestrooms/refugerestrooms/blob/develop/config/locales/es/contacts.es.yml seem to be for form feedback rather than the form itself.

[DeeDeeG]

I would recommend we add all the simple_form strings (that are missing when viewing in Spanish) to our simple_form.en.yml file, without commenting them out. This will override the default strings baked into the simple_forms gem, and make the strings load in a technically consistent manner between all locales (English wouldn't grab default strings from the gem, neither would other locales.)

Note: i18n-debug gem is really helpful for tracking down translation strings to add to [filename].en.yml.

Full thoughts/details below:

I think the simple-form gem has a lot of built-in default strings (English-only, it seems?).

Good news: the Rails i18n API is aware of those strings.

To check out the strings, install the gem i18n-debug, and on every page-load, the Rails server will print out EVERY translatable string in a format you can add to a translation strings file ([file].[locale].yml).

I meant to test this at some point, since I knew it "just worked" in English, and was hoping they had the fore-thought to translate to other languages.

Now that we know need these strings manually translated, how should we make that clear in our files? Should we add all the strings to our simple-form.en.yml (even though we only need them in the other locales beside English)? If so, should we comment them out in the en.yml file, so the defaults still technically get used? Or for consistency, should the en.yml file explicitly define all the strings, overriding the defaults baked into the simple_form gem?

Other option: Only add the remaining, "missing" translation strings for simple_forms to the simple_form.es.yml file and ask translators to start from the Spanish translation. (Fine if the next translator is comfortable with Spanish, not so great if the translator happens to be more comfortable with English.)

Benefit for doing it in the en.yml file (and necessarily also the es.yml file): Translators may start from the English or Spanish files, whatever they are comfortable with, or refer to both.

[mi-wood]

@Intimaria thanks! the first section also changed. I can update the file right after that

@DeeDeeG I'll start adding the defaults to the english file and we can go from there

[mi-wood]

I've created #446 for the labels. @Intimaria Can you either make a pull request or paste here with translations for those? I can update it and get this rolling!

[Intimaria]

@mi-wood Whoops! Yes, here is the first bit:

first: 'REFUGE es una aplicación por internet que busca proveer acceso seguro a baños para personas trans, intersexo, y personas género no conformes. Es posible buscar baños por proximidad a una ubicación, agregar nuevos baños a la lista, además de comentar y agregar un puntaje a los baños listados.'

Small ask:
I was using sanitarios, and changed them all to baños as it feels friendlier, but I seem to have missed two of those. One was in this corrected paragraph on line 6, so that's fine now, and it seems I also missed one sanitarios in line 9 of the same about file, if you could add that one (changing sanitarios to baños), that would be great too! So everything is coherent.

Forms:

labels:
      defaults:
        name: 'Nombre'
+        street: 'Calle'
+        city: 'Ciudad'
+        state: 'Estado/Provincia'
+        country: 'País'
+        accessible: 'Accesible'
+        unisex: 'Unisex'
+        changing_table: 'Con mesa para cambiar pañales'
+        directions: 'Indicaciones'
+        comment: 'Comentarios'
        email: 'Email'
        message: 'Mensaje'

+      contact:
+        name: 'Nombre'
+        email: 'Email'
+        message: 'Mensaje'

Submit would be Enviar

[DeeDeeG]

Otherwise, @Intimaria, if you do want to submit this as a new Pull Request, I recommend this workflow:

• Get on a branch matching upstream develop
  • If need be, you can simply get a fresh clone of the repo: git clone https://github.com/refugerestrooms/refugerestrooms new-refuge-folder
• Branch off to another branch
  • git branch new-branch-name and git checkout new-branch-name
    OR
  • git checkout -b new-branch-name
• Add these translations (probably in one commit.)
  • If you commit, but need to change something again, you can make changes, git add them, then git commit --amend (which pretends that your previous commit had all the changes you just git added and rolls the new changes into the old commit.)
• Push to your copy of the Github repo for RefugeRestrooms
• Start the PR from that branch using GitHub

[Edit]: Alternatively, I found a way to fake commit as another person, which even just mentioning is a bit like opening Pandora's box, and doing so would not generally be a good idea IMO, but it would be a way to give credit for these translations! (And it would be strange to fake a commit author, so... Not planning to do that, and if I get feedback that it sounds like a bad idea that would be another reason to not do it. Just mentioning, because it is indeed possible.)

[mi-wood]

All set and deployed!! Thanks so much to everyone who helped make this happen, especially @Intimaria! This is really awesome work.

[mi-wood]

Happy to tag anyone in this if they want: https://twitter.com/REFUGErestrooms/status/961043500488826881

[Intimaria]

Hi! My twitter is locked but you can add it if you like @animoveronica.

Edit: PS this is all very exciting. Do you know if it rolls out to the apps automatically or should we think through how it can be done?

[DeeDeeG]

PS this is all very exciting. Do you know if it rolls out to the apps automatically or should we think through how it can be done?

It does not roll out to the apps automatically. Well, they borrow the "submit a new restroom" page of the website. So it may work automatically on just that part of the apps.

Fortunately, there is a lot less text to translate in the mobile apps than the web app, as far as I can tell.

I don't personally have much experience with programming mobile apps, and I know the process there is likely to be a bit different, but it would be good to open an issue at those repos and get the discussion going for how to translate the apps:

• https://github.com/RefugeRestrooms/refugerestrooms-ios
• https://github.com/RefugeRestrooms/refugerestrooms-android

P.S. See this existing issue for translating the iOS app: RefugeRestrooms/refugerestrooms-ios#116
P.P.S. I started an issue for the Android app here: RefugeRestrooms/refugerestrooms-android#57