Bug #10469
i18n tasks attempt to translate QubitSetting fixtures
Status: | Verified | Start date: | 10/24/2016 | |
---|---|---|---|---|
Priority: | High | Due date: | ||
Assignee: | - | % Done: | 0% | |
Category: | I18N | Estimated 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
History
#1 Updated by Jesús García Crespo over 5 years ago
- Related to Bug #10256: Treeview does not appear when using certain cultures added
#2 Updated by Jesús García Crespo over 5 years ago
- Description updated (diff)
#3 Updated by Nick Wilkinson over 5 years ago
- Assignee set to José Raddaoui Marín
#4 Updated by José Raddaoui Marín over 5 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 5 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 5 years ago
I like it, thanks Sevein!
#7 Updated by José Raddaoui Marín over 5 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 5 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 5 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 5 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!