Wordpress-ios: Translations in Zendesk

[charliescheer]

Hey y'all. I started answering questions in Zendesk for the first time today, and I noticed that there are some things being translated that maybe shouldn't be. The first one that I noticed was the device storage amount, shown here which is displaying in Arabic. As I looked around I found a few other things that were translated, like WordPress in the title of the message and the plan type were showing in Arabic as well.

If you check out this issue https://woothemes.zendesk.com/agent/tickets/1232054 you can see the areas that are translating. I don't think these translations are going to cause a huge problem for us working in Zendesk, but wanted to point it out.

[ScoutHarris]

Hey @charliescheer .

I finally figured out how the Plan Title is getting translated - it's coming directly from the WP API. I wasn't expecting this, but when I change the device language, shortly thereafter the Plan Title provided to the app is translated.

That's resulting in these two issues:

• A translated Plan tag
  

• A translated Plan in the blog information
  

To circumvent this, I can manually add these Plan Titles according to Plan ID:

• Free
• Premium
• Professional
• Personal
• Business

The only drawback is if there is a new plan in the future it won't get picked up. As a default, I'll use 'unknown'.

Thoughts?

cc @aerych

(FYI - I'm still looking into the other issues.)

[aerych]

I'm already looking at making a change to the plans endpoint, which seems to be where we're getting the title. Let me see if there's a way we can return an untranslated version of the plan title in a way that makes sense.

[ScoutHarris]

Hey @charliescheer .

Regarding the ticket Subject. The app is translating that because it gets displayed to the user when they view a ticket:

Zendesk simply shows the Subject as-is. So if the app doesn't translate it, it shows in English:

I scanned some mobile tickets, and you noted this as well - "iOS" and "Android" don't get translated, so the HEs can still determine which platform tickets pertain to.

Are you ok with leaving the Subject translated so it appears correctly for users?

[aerych]

Re: https://github.com/wordpress-mobile/WordPress-iOS/issues/9625#issuecomment-399576328

To circumvent this, I can manually add these Plan Titles according to Plan ID:

I notice the endpoint returns a field for product_slug that we're not currently checking in the apps. The product_slug might be sufficient. The values returned are:

free_plan for Free plan
value_bundle for Premium plan
business-bundle for Business plan
personal-bundle for Personal plan

(note the the inconsistent use of - and _)

Any new plans should have a similar slug.

Perhaps the apps could return this field in lieu of or in addition to the plan title?

[ScoutHarris]

@aerych hrm... looking at the API console, there's also:

jetpack_free => Jetpack Free plan
jetpack_premium => Jetpack Premium plan (2000)
jetpack_business => Jetpack Professional plan
jetpack_personal => Jetpack Personal plan (2005)
jetpack_premium_monthly => Jetpack Premium plan (2003)
jetpack_personal_monthly => Jetpack Personal plan (2006)

So, if we used the product_slug, the HEs would certainly get _detailed_ plan information. 😄

[charliescheer]

Thanks for looking into this y'all!!

[ScoutHarris]

Hey @charliescheer . The translated timestamp in the logs will be fixed in the next release (10.4). Fixed on https://github.com/wordpress-mobile/WordPress-iOS/pull/9644.

[ScoutHarris]

@charliescheer - and now the Free Space translation is fixed. Will be in 10.4, fixed with https://github.com/wordpress-mobile/WordPress-iOS/pull/9649.

[ScoutHarris]

Hey @aerych .

If I recall correctly, your effort to do this met with some resistance.

I'm already looking at making a change to the plans endpoint, which seems to be where we're getting the title. Let me see if there's a way we can return an untranslated version of the plan title in a way that makes sense.

But I noticed you're currently modifying the Plans endpoint. Is this change by chance included?

[aerych]

Yep yep! Sadly no eta on when I'll have it ready. I'm working on the endpoint as I find free time, which has been in short supply lately.

[ScoutHarris]

Hey @aerych . I know it's been a while, but what ever happened with the endpoint?

[aerych]

Sorry I was vacationing when this ping came through.

This slipped through the cracks. Mea culpa. The good news is we can update the new endpoint with what we need. Are we still looking to use an untranslated plan title? If so I can add that field to the endpoint and we can update the plans model in the app to store it. Then it should just be a matter of matching the plan details to the plan id stored in the blog model. Let me know!

[charliescheer]

I would think so. I have gotten pretty good at recognizing the plan code, but with the new plans and the new people it might be better to have them appear in english

[aerych]

I took a closer look at how we're adding the plan information to Zendesk and have been thinking about the best approach to provide a non-localized title with Zendesk tickets.

It looks like whenever a ticket is created [Blog supportDescription] is called which adds the blog's plan ID and plan title as meta data, and this is done for _every_ blog in the app. This information is localized and stored in the Blog model as a result of a call to public-api.wordpress.com/rest/v1.1/sites/%s. This endpoint will also return a Jetpack plan if the blog has one (good to know).

Options as I see them:

1. When the support screen is launched call the /v1.1/me/sites endpoint specifying locale=en for English titles and fields=plan to limit the results to just the plans info. Cache the response and use it to provide the non-localized titles.
   Pro: Plan data will always be accurate to the blog. Its only fetched on demand. No need to store unused data.
   Con: Network latency could mean a ticket is opened before the information is synced. Would not be available offline.

2. Add a new call to public-api.wordpress.com/rest/v1.5/plans. Call it once per launch as a strategy to not over query and still have current data. (Optionally make this a just-in-time request but I'd consider option 1 as the superior strategy in that situation.) Store the result until its needed. The results from this endpoint include the latest wpcom plans.
   Pro: Same endpoint used by marketing so information is current.
   Con: No guarantee this endpoint won't go away or be depreciated in favor of another. Issues with the plans endpoints historically. We'd still fetch more data than needed.

3. Add a new section to the wpcom/v2/plans/mobile endpoint that we use for the My Site > Site > Plans feature that lists _all_ wpcom and Jetpack plan IDs and titles. (Currently only wpcom plans are returned). Let this sync as it normally does. Cache the information for when its needed.
   Pro: We already have the endpoint wired up, we'd just need to consume the added information.
   Con: This would dilute the purpose of the wpcom/v2/plans/mobile endpoint, but seems necessary to provide non-localized Jetpack plan titles.

After thinking this through, I'm leaning to Option 1 as the best approach. The latency issue _seems_ relatively minor to me (or I'm being biased). I'm not a fan of option two or three due to the wasted bandwidth. Option 2 has me a bit uncomfortable with its reliance on the v1.5 endpoint for ... reasons. Option 3 relies on an endpoint we control but adding the Jetpack titles seems like a hack and I think we need them to properly deliver what's being asked.

@ScoutHarris would appreciate your thoughts. Do you see any issue with fetching non-localized site plan details when support is accessed?

[ScoutHarris]

Hey @aerych . Thank you so much for looking into this, and providing possible solutions.

Do you see any issue with fetching non-localized site plan details when support is accessed?

It seems reasonable and doable. I'll give it a go!

[ScoutHarris]

Assigned to @aerych since he offered to actually implement fetching non-localized site plan details when support is accessed.