Problem/Motivation

When adding a new webform, the current interface language is used as original language.
If a content editor uses English as interface language, you always get an English translation of a webform, even if it is not needed in the system.
When you have language-specific content that is not translated to any other language, the webform should also only exist in the required language(s) not in the authors interface language.
At the moment, editors are forced to switch to a different interface language, to prepare a webform that uses the targeted language as original language, even if they can't read the button labels.

Steps to reproduce

Proposed resolution

Add a select box to choose the original language on webform add form, just like it exists for content translation. The interface language should be set as default value.

Remaining tasks

User interface changes

Additional select box to choose the original language on webform add form.

API changes

none

Data model changes

none

Comments

mkalkbrenner created an issue. See original summary.

mkalkbrenner’s picture

Status: Active » Needs review
StatusFileSize
new884 bytes
renatog’s picture

Status: Needs review » Needs work

#2 is good, but I'd suggest verify the options number and if there is only set we can set the select as "disabled" because don't make sense allow the user to select but we have only 1 option. So I think will improve the User Experience (UX)

renatog’s picture

Status: Needs work » Needs review
StatusFileSize
new1.01 KB
new510 bytes

Something like this. What do you think?

jrockowitz’s picture

The code from #4 is untested because it does not disable the ''langcode' dropdown. It feels like you are making code suggestions just to get a commit credit. Please slow down with your reviews and patches.

I think your suggestion is okay but we could only render the dropdown if it has more than 1 option.

mkalkbrenner’s picture

@jrockowitz What about the patch in #2 in general? Do agree with my issue description?
We use the patch in production now and the editors are happy.

jrockowitz’s picture

The patch from #2 makes sense. I need to download and test the patch locally. Maybe someone else can verify the patch.

jrockowitz’s picture

It feels like you are making code suggestions just to get a commit credit.

@RenatoG I want to apologize for making this accusation. You have helped with a lot of tickets. It is important that every comment and patch it helps solve the task at hand.

jrockowitz’s picture

StatusFileSize
new2.23 KB

Attached patch incorporate the suggestion from #4 using #access and includes some test coverage.

  • jrockowitz authored 2e488f8c on 6.1.x
    Issue #3345252 by RenatoG, jrockowitz, mkalkbrenner: Webforms are always...

  • jrockowitz authored 2e488f8c on 6.x
    Issue #3345252 by RenatoG, jrockowitz, mkalkbrenner: Webforms are always...

  • jrockowitz authored 2e488f8c on 6.2.x
    Issue #3345252 by RenatoG, jrockowitz, mkalkbrenner: Webforms are always...
jrockowitz’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

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

renatog’s picture

It feels like you are making code suggestions just to get a commit credit

@jrockowitz you're wrong

  • D.O don't have "commit credit"
  • Currently is "issue credit"
  • Doesn't matter who is the "commiter"
  • Personally speaking I definitely don't need this

slow down with your reviews and patches

Sorry but you can't ask that, it's a democracy

  • It's open-source project
  • Everyone are free to make contributions
  • If you think that isn't useful, as maintainer you can disable the credits on Credit & committing
  • But you can't block any user to contribute if people wants
  • You must respect everyone
  • I recommend you to read Drupal Code of Conduct

@RenatoG I want to apologize for making this accusation. You have helped with a lot of tickets. It is important that every comment and patch it helps solve the task at hand

That’s ok