Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Due to a patch (don't know what patch), the welcome page (no nodes are present) is not translateable anymore becasue it's not included in the translation template. Someone split up the string into three parts where the middle part is inserted conditionally. Obviously, this doesn't work as extractor.php doesn't recognize that.
Comment | File | Size | Author |
---|---|---|---|
#15 | welcome_translate_0.patch | 5.54 KB | kkaefer |
#1 | welcome_translate.patch | 5.55 KB | ChrisKennedy |
Comments
Comment #1
ChrisKennedy CreditAttribution: ChrisKennedy commentedConfirmed, this was due to http://drupal.org/node/60358
The attached patch breaks the section into smaller strings that are individually translated, taking html markup out where possible while still providing context to the translators. I confirmed that it doesn't break the English version, but let me know if it is actually good for translators & extractor.php.
Comment #2
kkaefer CreditAttribution: kkaefer commentedSeems good to me. Solves the problem. Small parts are also easier to translate.
The patch that broke this is not #60358. This patch only introduced the new frontpage which was a single translateable string at that time. A later patch split out the first list item which is since included conditionally.
Comment #3
ChrisKennedy CreditAttribution: ChrisKennedy commentedAh good call, http://drupal.org/node/93289 was the problem and was much more recently committed. I didn't check the previous issue well enough apparently.
Comment #4
webchickSorry guys, this was my fault. :(
However, I was told that we should be leaving the
and- s together, because it adds additional context to the string being translated. But in any case, we can't go changing strings around anymore because we're past RC1 and translation has begun. Therefore, I'd just stick the middle part in a t() so that it can be translated and leave it at that.
Comment #5
webchickBah. That should read "ols" and "lis"
Comment #6
ChrisKennedy CreditAttribution: ChrisKennedy commentedIn this case we can actually strings around as much as want. It doesn't regress any previous translation work because this string wasn't available for translation in the first place. I don't see the benefit to including the <li>'s in the translation, but I'm not a translator so if that's helpful I guess they should be in there.
I do think that breaking up the string is better though -> it makes it less volatile for translations and is easier to debug with all the @variables. You could also re-order it if you wanted to.
Comment #7
ChrisKennedy CreditAttribution: ChrisKennedy commentedBlegh. "In this case we can actually strings around as much as want." -> "In this case we can actually move strings around as much as we want."
Comment #8
webchickNo, the rest of the message was translatable before. So it's conceivable I have already translated the precise string:
Changing that to instead 5 strings like:
and:
and so on, you will break the translations.
Comment #9
ChrisKennedy CreditAttribution: ChrisKennedy commentedThat's true if you began translating node.module before November 26th (during beta2), but it isn't related to the string freeze. The string freeze didn't begin until December 15th, at which point that section of node.module would not have been available to extractor.module.
Comment #10
webchickOhhh, wait. I might be wrong because of the conditional part.
In that case, I'll mark it back for review, pending someone working on translations to tell the proper way to solve this.
Comment #11
kkaefer CreditAttribution: kkaefer commentedWebchick, currently the string is not included in the translation templates. Not even parts of it. ChrisKennedy's solution is preferable IMO (I'm a translator and prefer translating smaller parts instead of huge strings with lots of markup inside).
Comment #12
ChrisKennedy CreditAttribution: ChrisKennedy commentedOne discussion is whether the <li>'s should be included in the translated strings. A point brought up by webchick (hopefully I paraphrase appropriately) in #drupal is that http://drupal.org/node/26139 suggests that we should include them in the strings. My own non-translator thought is that the <li> tags don't help the translators, considering that they don't know what specific number/order they will be, and they would be better abstracted to allow flexibility in markup and ordering.
So, my initial thought it that translators don't need to the <li> hints - but if they are helpful I am fine with keeping them in the translatable strings.
Comment #13
webchickYeah, in thinking this over more I think that's fine... the deal with the help text was that the actual entire "train of thought" was "You can: (something in the list of links)" so the big lump of text was needed in order to express the complete sentence.
Setting back to RTBC. Sorry for the de-railing. ;)
Comment #14
drummCode style- there should be no space between . and quotes.
Comment #15
kkaefer CreditAttribution: kkaefer commentedSame patch without the whitespace.
Comment #16
drummCommitted to HEAD.
Comment #17
(not verified) CreditAttribution: commented