pull out copy that is currently hardcoded

[mikefantini]

@julielorch @mnelson338 are currently working on a draft of this list.

Includes everything from "Step One: Know It" on the campaign page to "Log In" button on authentication modal

this should all be put into the DoSomething Configuration -> Do Something Campaign

[DFurnes]

Out of curiosity, why not just handle this with built-in translation via t()?

[mshmsh5000]

@DFurnes +1, that's what @sergii-tkachenko did in our first translation pass for Congo and Indonesia. This would be the POTX method of extracting translatable phrases into a translation template.

[mikefantini]

@DFurnes @mshmsh5000 - do you know why there is still so much English on indonesia.dosomething.org? is it that we just didn't add in the proper translation in these instances or did this method miss things?

i.e. Log In in header, authentication modal, tos and privacy policy, campaign "footer" on pitch page, headers on action page

[DFurnes]

There's probably some extra work (a la #4989) for things that we are exposing from the admin interface, but anything that's "hard-coded" should be translatable via the built-in translation interface. I just did a quick check and "Step One: Know It", "Log In", TOS & Privacy policy footer and links, and the campaign footer should all be translatable already.

[angaither]

Soooo, there's an admin interface to translate things passed through t() (new news to me) but it's v overwhelming. check this out on Indonesia there's 198 pages of strings to translate.

https://indonesia.dosomething.org/admin/config/regional/translate/translate/admin/config/regional/translate/translate

we can use t() but I think we will need to do some work on that page before exposing to anyone

[mshmsh5000]

Here's a sample POT extraction from the Paraneue theme files. I think breaking this out by component should provide a better method of tackling the work.

[mshmsh5000]

@mikefantini re: incomplete Indonesian translation, I think we just didn't complete all of the interface translation.

[mikefantini]

@mshmsh5000 thanks!

can you just clarify if this list is everything that should be hardcoded on US prod?

because one thing we can do is run through this and see if there is copy that we think is missing from this list

[mshmsh5000]

It's worth a manual double-check, yes. But one of the benefits of our v1 translation effort should be that this is a complete or nearly complete set of UI strings.

We need to do the same for our custom modules.

On Sep 2, 2015, at 12:20 PM, mikefantini notifications@github.com wrote:

@mshmsh5000 thanks!

can you just clarify if this list is everything that should be hardcoded on US prod?

because one thing we can do is run through this and see if there is copy that we think is missing from this list

— Reply to this email directly or view it on GitHub.

[mshmsh5000]

I've done a test integration of POEditor and Phoenix, enabled BR and MX, and invited a few of you as contributors.

One obvious pro is that this auto-extracts all 3200+ translatable terms from the platform.

One obvious con is that this is everything from the entire codebase, including all of the Drupal core terms. That will make it a PITA to go through. I'll look at the workflow options to see whether we can narrow down the translatable terms.

[mikefantini]

made a high priority, because this is one of the major things blocking @mnelson338 from getting a quote from a translator.

getting everything (including variable copy in configs) in the POEditor and separating out things like Drupal core terms will help @mnelson338 have a sense of how much translating needs to be done.

[mshmsh5000]

@weerd and I have figured out a workflow that should eliminate all core Drupal terms. Assigning to him, since he'll have the next updates.

After he does initial setup, the next task will be to audit what's in POEditor to see whether we're missing anything (e.g., copy stored as config variables).

[mshmsh5000]

(Oh right, he's already assigned... :tada:)

[weerd]

POEditor seems to do a rather nice job and will immensely help the effort in these translations.

Capabilities

The POTX module allows us to extract .po files for modules/themes individually. We can then import them into POEditor and I'd recommend clicking on the advanced options when importing so you can tag the import (e.g. campaign, reportback) which then lets you filter by these tags and only see associated terms for that tag.

Considerations

There are a few caveats to consider:

1) We may not want to use t() on #default_valuefields which have the value saved in the database, cause that's not getting pulled in via POEditor and instead extracting the name of the variable/placeholder @value:

'#default_value' => t("@value", ['@value' => variable_get($var_name)]),

In POEditor:

2) HTML in strings seems to sometimes be a little wonky with how it imports and not always close the tags. Might need some looking into.

---

Translation Stats

Here's the stats count based on the below modules/theme that were added to POEditor:

Total: 1,042 terms (5,585 words, 34,501 characters)

Modules/Themes Added for Translation in POEditor:

• dosomething_action_guide
• domsomething_campaign
• dosomething_campaign_group
• dosomething_campaign_run
• dosomething_fact
• dosomething_fact_page
• dosomething_home
• dosomething_image
• dosomething_kudos
• dosomething_notfound
• dosomething_reportback
• dosomething_reward
• dosomething_search
• dosomething_settings
• dosomething_shipment
• dosomething_signup
• dosomething_static_content
• dosomething_taxonomy
• dosomething_user
• paraneue_dosomething theme

Modules/Themes Not Added:

• dosomething_api
• dosomething_auto_translate
• dosomething_canada
• dosomething_global
• dosomething_helpers
• dosomething_mbp
• dosomething_metatag
• dosomething_northstar
• dosomething_payment
• dosomething_uk
• dosomething_zendesk
• securepages

Keep in mind that the items counted as terms/words etc are ones that have been set up to have the t() wrapped around them and some items show up a bit wonky, so the "total count" is a guesstimate at best!

[weerd]

¡Update-o Numero 2, OLÉ!

So the POEditor module seems to work for the most part, but Drupal needed an initial kick in the :peach: to get it to accept the translations.

Within the POEditor module, you can "Get all translations from POEditor", so Drupal will pull them all, however the interface wasn't showing the interface. I ended up Exporting the Spanish-MX translations from POEditor site, and then manually importing the file into Drupal. Once that happened, the translations started showing up. Following that, when I "Get all translations from POEditor" from Drupal now, it seems to pull everything down and translations show up (for the most part... seems to sometimes miss some and need to repull).

Good news is it works:

Bad new is, it doesn't register the text input values (e.g. "You did it!"), even if specified via a .po file.

[weerd]

¡Update-o Numero 2, OLÉ!

Something to note within template and with translations outputting properly...

This works:

<?php print t($subtitle); ?>

This does not work:

<?php t("@subtitle", ['@subtitle' => $subtitle]); ?>

[angaither]

:clap: :clap: :clap:

[weerd]

¡Update-o Numero 3, OLÉ!

Ok, so found some more stuff out. @angaither suggested trying to use the t() within the preprocess functions instead of the template, which as it turns out is actually better! And here's why... content that is formatted as markdown gets processed as such prior to being sent to the template, and if it gets changed, that means that the .po msgid (so the reference it stores in the pot file id to know what to replace) gets changed and no longer matches what's in the .po file and thus the translation replacement never happens!

So for example, say the following item is the value in database of a field in the configuration:

Sign up for a [campaign](/campaigns) and make the world suck less.

That's what we're aiming to store in the .po file as the msgid

#: dosomething_fact_page
msgid "Sign up for a [campaign](/campaigns) and make the world suck less."
msgstr ""

If t() is used in the template, then the string is changed to something like the following:

<p>Sign up for a <a href="/campaigns">campaign</a> and make the world suck less.</p>

So now the above doesn't match the original msgid and thus no replacement of translation happens.

Instead, if we use t() within the preprocess then we're using the same string before it gets changed by markdown which is great!

There are some items that I believe are just part of the passed $variables array and never get preprocessed and just straight up output ($subtitle comes to mind)... so we might have to for a slight preprocessing of these instances.

Also, we might need to make translators aware of items that contain markdown to know how to deal with it when translating, for example the:

Sign up for a [campaign](/campaigns) and make the world suck less

They would need to translate the "campaigns" in the parentheses, and not the stuff in brackets.

Important Note: Google Translate's translation of "... make the world suck less." is pretty amusing if you know spanish ;)

[weerd]

@mikefantini can we close this issue?

[weerd]

Ok, so all the strings we could find that needed to be extracted and imported into POEditor to get a word count has happened so closing this issue. If there's additional strings that we need and missing from POEditor, let's add them as individual issues.