Problem/Motivation

The locale + config translation integration treats strings the same way locale itself does. If t('Drupal') appears in class A and module B, then the translations will be the same. If 'Frontpage' appears in config file X and config file Y and two separate occurrences within config file Z, then all of those would be translated the same in config/locale. If one of them is updated, the rest will be updated. Context may be provided on the configuration schema level like in t() to make strings unique. There is no automated configuration context.

Proposed resolution

Document that this is the case.

Remaining tasks

Figure out where to do it.

User interface changes

None.

API changes

None.

Files: 
CommentFileSizeAuthor
#10 interdiff.txt1.84 KBjhodgdon
#10 2460823-docs-update-10.patch5.77 KBjhodgdon
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 90,710 pass(es). View

Comments

Berdir’s picture

Gábor Hojtsy’s picture

Not sure I understand the question. The locale + config translation integration is built for shipped config, that is all the config that was part of projects when you installed them. The integration exposes all source strings in those configs in locale on the regular "built-in user interface" translation UI so you can translate user roles, formats, content types, etc. The integration also allows localize.drupal.org to feed translations to the site. Uniqueness for these strings are managed the same way as for strings in t(). So long as there is no context provided, they are global. So if you translate 'Drupal' on localize.drupal.org, that translation will apply too all occurances of that string in default configuration too where no explicit context was provided to make the string more unique. That also means that if you locally update the translation to 'Drupal', all config translations which had that source string will be updated with the new translation. If you update one of the config translations changing the translation there, it will feed back to locale. (It seems to be a bug that in this case all other config that may have the same source string are not updated, but that would be consistent with the behavior for the other cases).

Does that answer the question?

Gábor Hojtsy’s picture

jhodgdon’s picture

OK...

Here's the main D8 i18n topic on api.d.o:
https://api.drupal.org/api/drupal/core!modules!system!language.api.php/g...

It seems like on this topic, we should mention that:
- Translatable config stuff is also on localize server
- The general principle that string translations are shared for UI text
- Something about context to break the sharing

Then this topic links to https://api.drupal.org/api/drupal/core!modules!system!core.api.php/group... to talk about configuration, but that topic doesn't seem to say anything about translation or internationalization at all.

I think what we should do is take the last paragraph of the YAML files section in that topic, which talks about schema files, and separate it out into a new section called "Schema and Configuration Translation". That paragraph already talks about which config schema types are translatable, but we'd add:
- How to designate translatable in new config schema types (maybe?)
- The information in the summary of this issue about string sharing
- Something about context to break the strings

Gabor: I don't know what to write about contexts, but I could write the rest... so either maybe you could take a first pass at writing an I could edit, or you could add a few notes on what to write about contexts and I could take the first pass?

Gábor Hojtsy’s picture

So strings with t(), *.links.yml, Drupal.t(), default config strings, TWIG, routing.yml, etc. are unique per string. Contexts may be provided for each:

// PHP
t('May', array(), array('context' => 'Long month name');
format_plural($count, '1 something', '@count somethings', array(), array('context' => 'My context'));

// JS
Drupal.t('May', {}, {'context': 'Long month name'}
Drupal.formatPlural(count, '1 something', '@count somethings', {}, {'context': 'My context'});

// *links.yml
title: 'May'
title_context: 'Long month name'

// Config schema (assigns the context to the data when parsed)
date_format:
  type: string
  label: 'PHP date format'
  translatable: true
  translation context: 'PHP date format'

// Edit: note that 'PHP date format' it itself a translatable string that cannot get a context

// routing.yml
something:
  pattern: '/something'
  defaults:
    _title: 'May'
    _title_context: 'Long month name'

// TWIG
{% trans with {'context': 'Long month name'} %}
  May
{% endtrans %}

There may be others I am missing, these came to mind quickly. The contexts would make them unique only in that context. So if someone translates 'May' it would not show up in the given TWIG, routing, etc. situations unless it was done within the 'Long month name' context. (String context is displayed on the interface translation UI, its passed over in the .po files and displayed on localize.drupal.org too with each string).

Hope this helps @jhodgdon.

jhodgdon’s picture

Status: Active » Needs review
FileSize
5.59 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 90,647 pass(es). View

Here's a first pass. I decided to centralize the info on the i18n topic, and not put details in the Config topic.

Status: Needs review » Needs work

The last submitted patch, 6: 2460823-docs-update.patch, failed testing.

Status: Needs work » Needs review

jhodgdon queued 6: 2460823-docs-update.patch for re-testing.

Gábor Hojtsy’s picture

Status: Needs review » Needs work
Issue tags: +sprint

Patch looks good :) Some notes:

  1. +++ b/core/modules/system/core.api.php
    @@ -236,21 +236,27 @@
    + * types label, text, and data_format in configuration schema are translatable;
    

    date_format

  2. +++ b/core/modules/system/language.api.php
    @@ -77,12 +77,74 @@
    + * buttons on them, and they all would have t('Submit') in their code. The
    

    We don't actually suggest to use the button label "Submit" on submit buttons for UX reasons. We use "Save configuration" for example. The most widespread example in earlier Drupal versions at least was "Operations", that is one of the most widely used source strings. Not suggesting you completely change up the example, but maybe using "Save" or "Save configuration" would be better to follow UX guidelines.

+1: Add that labels defined in config schema themselves are also translatable. They cannot provide a context though for the translation of themselves.

jhodgdon’s picture

Status: Needs work » Needs review
FileSize
5.77 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 90,710 pass(es). View
1.84 KB

How's this?

Gábor Hojtsy’s picture

Status: Needs review » Reviewed & tested by the community

Looks good to me! Documents the status quo well. Thanks for your help with this!

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed 1150693 and pushed to 8.0.x. Thanks!

  • alexpott committed 1150693 on 8.0.x
    Issue #2460823 by jhodgdon: Document that locale + config translation...
Gábor Hojtsy’s picture

Issue tags: -sprint

Yay, thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.