On this site I'm currently developing I have English as the default language, and I have German as well. In the translation table I have one column "Original" which show my original/default/english strings, a column for translating my strings into German, but I also have a column for English where I can translate my English strings into English.

What's the point of this column?

It's confusing to me and it will no doubt be hugely confusing to the people who will administer this site in the end. I've even tried writing something in the English column and it changes nothing.

In my mind there should be a column with the original strings and a column for me to type in the German translation, there's no need for the English column.

CommentFileSizeAuthor
#9 translation_table-636126.patch9.92 KBjonhattan
#8 translation_table-636126.patch9.92 KBjonhattan
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Pasqualle’s picture

Pasqualle
Location 🇭🇺 Budapest
CreditAttribution: Pasqualle commented
Version: 6.x-1.0-rc2 » 6.x-1.x-dev
Category: support » bug

I think you are right, the language column which is the same as the default language should be removed.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
CreditAttribution: agentrickard commented

We have a different use-case. Using Domain Access, we have different primary languages per domain, so removing this behavior might cause us problems.

Pasqualle’s picture

Pasqualle
Location 🇭🇺 Budapest
CreditAttribution: Pasqualle commented

@agentrickard:
I am not sure how would it cause a problem as I just want to remove the column which is unusable, that means
on domain 1: Source (English) | German | French
on domain 2: Source (German) | Hungarian
where the Source is not editable, as it is the source which can not be translated..

does it make sense, or is it just wrong somehow?

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
CreditAttribution: agentrickard commented

Not sure. If you role a patch, I can test it pretty easily. The default language changes per domain, and we want to make sure that the absence of a language on one domain does not cause the string to be deleted. For instance:

Main site:
Default: English
Enabled: French, German, Japanese, Greek

Subsite:
Default: Greek
Enabled: English

Subsite:
Default: German
Enabled: French, English

So my concern is that if the form removes some elements, we may accidentally delete data.

markus_petrux’s picture

markus_petrux CreditAttribution: markus_petrux commented

I think this is related to a more or less hidden new feature in i18n: #676002: optionally translate default language in tt()

In other words: translation of the default lang can now be enabled/disabled.

Pasqualle’s picture

Pasqualle
Location 🇭🇺 Budapest
CreditAttribution: Pasqualle commented
Component: Miscellaneous » User interface
Category: bug » feature

yes, translation_table should use the i18nstrings_translate_langcode($langcode) function, otherwise users will not understand why the string can or can not be translated to given language.

solution:
display the language selection as "Language name (no translation)" for languages where i18nstrings_translate_langcode($langcode) == FALSE and display a link to handbook page (after it is created) #938422: Please provide documentation about i18nstrings_translate_langcode_xx

GiorgosK’s picture

GiorgosK
Location Chios, Greece 🇬🇷
CreditAttribution: GiorgosK commented

just for reference how to translate default language

jonhattan’s picture

jonhattan
Primary language Spanish
Location Plasencia
CreditAttribution: jonhattan commented
Version: 6.x-1.x-dev » 7.x-1.x-dev
Status: Active » Needs review
FileSize
translation_table-636126.patch9.92 KB

Here's a patch to hide the default language if it's not translatable.

jonhattan’s picture

jonhattan
Primary language Spanish
Location Plasencia
CreditAttribution: jonhattan commented
FileSize
translation_table-636126.patch9.92 KB

This is the good one

David Lesieur’s picture

David Lesieur CreditAttribution: David Lesieur commented
Status: Needs review » Needs work

Last patch does not seem to apply to current 7.x-1.x-dev version:

patching file modules/field.translation_table.inc
patching file modules/menu.translation_table.inc
Hunk #1 FAILED at 23.
Hunk #2 succeeded at 40 (offset -1 lines).
Hunk #3 FAILED at 149.
2 out of 3 hunks FAILED -- saving rejects to file modules/menu.translation_table.inc.rej
patching file modules/node.translation_table.inc
patching file modules/quicktabs.translation_table.inc
patching file modules/taxonomy.translation_table.inc
patching file translation_table.module
devad’s picture

devad CreditAttribution: devad commented
Issue summary: View changes

#9 patch is adjusted and used here: #2543878: Multiple fixes and improvements. Block and views support added