Selecting an alternative language loses any translation unsaved

Bug #80278 reported by Carlos Perelló Marín
2
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
Low
Unassigned

Bug Description

The alternative language selector works like a GET request, that produces that if we have some translation unsaved, it will be lost.

We should move it to be a POST so those translations are not discarded.

Revision history for this message
Carlos Perelló Marín (carlos) wrote :

We got this comment from Matthew:

There is a little confusion here.

First, things that look like they're accepted by the same submit
button, or seem like they should be accepted by the same submit button,
should use a single <form>. This is because it's polite not to ignore
people's input, and if you use multiple forms, someone making changes
in both of them and submitting one will unexpectedly have some of their
changes ignored.

We have that problem in the bug page, for example: if you enter a
comment in the main comment field, then decide to change the bug's
status, either your comment or the status change will be ignored.
<https://launchpad.net/bugs/57414> (Similarly if you try to change the
status in multiple targets at once, most of your changes will be
ignored.)

Whether to use <form ... method="get"> or <form ... method="post"> is
mostly a separate problem. (Remember that in XHTML, "GET" and "POST"
are invalid: use "get" and "post" instead.) Use method="get" when
repeating the action does not make a mess. The resulting URLs should
make sense when bookmarked or e-mailed; they can be returned to later.
Use method="post" for a form that creates something, where repeating
the submission would would not be a good idea; the translation page is
an example of this. <http://www.w3.org/2001/tag/doc/whenToUseGet.html>

Where these two issues intersect is where you need to combine two or
more forms to fix the dataloss problem, but one of them is using "get"
and the other "post". An example of this is merging the alternate
language selector, the tranlsation filter, and the translation fields
into a single form: the first two use "get", and the last uses "post".

I think the answer here is to use "post" for the merged form, but to
redirect to an URL that includes the data entered using those parts of
the form that were previously "get". For example, if you both change
the alternate language and enter some translations, the resulting URL
should contain the alternate language you selected (so that you can
bookmark that URL and return to it), but it should not contain all the
translations you entered.

Changed in rosetta:
importance: Undecided → Medium
status: Unconfirmed → Confirmed
Revision history for this message
Matthew Paul Thomas (mpt) wrote :

While the partly-done translations shouldn't be thrown away, it would also be unexpected to accept them as translations, since you haven't clicked "Save & Continue".

Ideally, if you're just changing the alternate language, the page would reload with the translations you've filled out so far still there in the fields, but not yet accepted as translations. (If you're also changing the filter, then I think it would be ok to discard anything you entered for a string that no longer appears with the new filter.)

Changed in rosetta:
importance: Medium → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.