Bug #10469

i18n tasks attempt to translate QubitSetting fixtures

Added by Jesús García Crespo over 3 years ago. Updated about 3 years ago.

Status:VerifiedStart date:10/24/2016
Priority:HighDue date:
Assignee:-% Done:

0%

Category:I18NEstimated time:8.00 hours
Target version:Release 2.4.0
Google Code Legacy ID: Tested version:
Sponsored:No Requires documentation:

Description

We're wasting other people's time here if we ask them to translate our settings. It's also been a problem to have settings translated whey we were not expecting them, see https://projects.artefactual.com/issues/10256.

Unless they are UI labels. Are there other cases?

It's probably a matter of tweaking QubitI18nConsolidateExtract.class.php.


Related issues

Related to Access to Memory (AtoM) - Bug #10256: Treeview does not appear when using certain cultures Verified 09/02/2016

History

#1 Updated by Jesús García Crespo over 3 years ago

  • Related to Bug #10256: Treeview does not appear when using certain cultures added

#2 Updated by Jesús García Crespo over 3 years ago

  • Description updated (diff)

#3 Updated by Nick Wilkinson over 3 years ago

  • Assignee set to José Raddaoui Marín

#4 Updated by José Raddaoui Marín over 3 years ago

  • Status changed from New to In progress

Hi Sevein,

Looking at the settings, we have two scopes that should allow translations: 'ui_label' and 'access_statement', and a couple of settings more: 'siteTitle' and 'siteDescription'. So I was thinking in adding a new column (translatable) to the setting table. But in the end it looks like the only ones handled via fixtures are the 'ui_label' settings, so adding an "$item['scope']" check in this case may be enough for the moment.

Do you have other ideas?

#5 Updated by Jesús García Crespo over 3 years ago

So I was thinking in adding a new column (translatable) to the setting table. But in the end it looks like the only ones handled via fixtures are the 'ui_label' settings, so adding an "$item['scope']" check in this case may be enough for the moment.

I think the extra column could be a better solution but I agree, it seems overkilling. However, the simplest alternative introduces more complexity for the future developer. If you put software maintainability first you'd probably go with the solution that doesn't require a new developer to know about an extra change in QubitI18nConsolidateExtract.

An alternative could be to add a new static property to the very top of QubitSetting listing the settings (by their names or scopes) that can be translated - similar to the `$lockedTaxonomies` member of QubitTaxonomy. Would that work? At least it would be more visible.

#6 Updated by José Raddaoui Marín over 3 years ago

I like it, thanks Sevein!

#7 Updated by José Raddaoui Marín over 3 years ago

  • Status changed from In progress to Code Review
  • Assignee changed from José Raddaoui Marín to Jesús García Crespo

#8 Updated by Jesús García Crespo over 3 years ago

  • Status changed from Code Review to Feedback
  • Assignee changed from Jesús García Crespo to José Raddaoui Marín

LGTM

#9 Updated by José Raddaoui Marín over 3 years ago

  • Status changed from Feedback to QA/Review
  • Assignee changed from José Raddaoui Marín to Dan Gillean

Hi Dan, to test this I think we should wait until the next Transifex push and, if setting values like 'pdf', 'inventory-sumary', etc. are not available to translate it should be okay.

#10 Updated by Dan Gillean about 3 years ago

  • Status changed from QA/Review to Verified
  • Assignee deleted (Dan Gillean)

We just did a push to Transifex, and I could not find those terms - I think it worked!

Also available in: Atom PDF