this task has 2 things missing:

• when we start a translation there is no sentence selected so the ... button does nothing when we tap it
• on desktop, no sentence shows up to translate
  

is this to be fixed on this task or different ones @Pginer-WMF ?

In T259503#6458670, @Jpita wrote:

this task has 2 things missing:

• when we start a translation there is no sentence selected so the ... button does nothing when we tap it

I think it would be worth it to probably do both:

• Make sure that there is an initial selection. This makes the workflow more fluent.
• Make sure that in the event that for whichever reason there is not a selection, the card does not provide misleading options. That is, the "..." is disabled.

• on desktop, no sentence shows up to translate
  

is this to be fixed on this task or different ones @Pginer-WMF ?

The lack of an initial selection may get in the way of the user to complete this step, so I think it could be part of the main task. However, if that requires a significant amount of work, it is ok to create a separate ticket for it.

Should it be moved to in progress then?

In T259503#6460306, @Jpita wrote:

Should it be moved to in progress then?

Apart from this, when selecting a sentence, is the rest according to the spec?

If this is the only missing piece we can create a follow-up ticket, but i'd like to get a better understanding about whether the core aspects of the ticket are completed and which ones are the missing pieces to either create separate tickets or consider the ticket incomplete.

follow up task created T263015

In T259503#6465789, @Jpita wrote:

follow up task created T263015

Apart from the missing pieces captured in T263015, we may want to capture other aspects that don't comply with the spec. From what I see in the testing server the implementation looks different compared to the spec in several aspects that have not been mentioned or captured in separate tickets:

Spec	Implementation

• Layout needs adjustment. Implementation shows a panel that is not taking the whole screen width. It was intended to be full width, with a grey background and the options should be shown as cards.

• Option to start with an empty sentence needs adjustment. In the current implementation a text area was added. In the spec it was intended as a blank card with a visual element to represent the input cursor.

• Links should not navigate away. When taping a card, the current implementation leads the user out of the tool. We may want to keep the link styling but make them non-interactive to make the whole card to be a single element to select.

I'll create follow-up tickets for the above, but feel free to share any other aspects you checked or are pending to check as part of the QA process. Even if the missing pieces are not implemented immediately, it is important to capture them in tickets to make sure they are eventually done.

Created the three follow-up tickets:

• T263146: Alternative MT selection: adjust layout and style
• T263148: Alternative MT selection: start with an empty sentence needs adjustment
• T263150: Alternative MT selection: Links should not navigate away

Moving back to QA for further checking. If no additional mismatches with the spec are found, this can be resolved.

In T259503#6473812, @Pginer-WMF wrote:

Moving back to QA for further checking. If no additional mismatches with the spec are found, this can be resolved.

I had already moved to done, should I check for anything else?

In T259503#6474830, @Jpita wrote:

In T259503#6473812, @Pginer-WMF wrote:

Moving back to QA for further checking. If no additional mismatches with the spec are found, this can be resolved.

I had already moved to done, should I check for anything else?

In T259503#6470374 I reported some issue I found on first sight that were not flagged during QA but I had not looked into all details of the spec for the ticket (spacing, functionality, transitions). So I thought it would be good for you to check in QA since I'm not sure how deeply that was reviewed the first time (notes about that would be helpful in general to facilitate coordination).

In T259503#6470374 I reported some issue I found on first sight that were not flagged during QA but I had not looked into all details of the spec for the ticket (spacing, functionality, transitions). So I thought it would be good for you to check in QA since I'm not sure how deeply that was reviewed the first time (notes about that would be helpful in general to facilitate coordination).

ooohhhh, I was assuming since the developers have the specs they should be the same as the implemented in the app...
OK, will check that going forward, thanks

In T259503#6474849, @Jpita wrote:

In T259503#6470374 I reported some issue I found on first sight that were not flagged during QA but I had not looked into all details of the spec for the ticket (spacing, functionality, transitions). So I thought it would be good for you to check in QA since I'm not sure how deeply that was reviewed the first time (notes about that would be helpful in general to facilitate coordination).

ooohhhh, I was assuming since the developers have the specs they should be the same as the implemented in the app...
OK, will check that going forward, thanks

Perfect. Thanks!
Most may be aspects to support later as follow-up tickets (some left out intentionally by developers for future iterations), but I think it is worth flagging and capturing in tickets to avoid those falling to the cracks.

Perfect. Thanks!
Most may be aspects to support later as follow-up tickets (some left out intentionally by developers for future iterations), but I think it is worth flagging and capturing in tickets to avoid those falling to the cracks.

if they are aspects to support later as follow-up tickets I need to know so I don't lose my time with that (that was my first thought hence me not looking at that).
Please leave the description with only the things I need to test and put the rest in the follow up tickets.

@Jpita Jumping in here to help with some clarifications so that it's easier for you to monitor things (@Pginer-WMF please correct me if I'm wrong): Pau has already split this ticket to remaining subtasks and since this is not a huge ticket, I believe that the only things to check for this specific ticket (excluding child tickets) are paddings/margins, colors and font-sizes for translation options (original sentence, google, yandex, empty sentence etc) and card header titles. Everything else is already captured in newly created tickets by Pau.

In T259503#6474870, @Jpita wrote:

if they are aspects to support later as follow-up tickets I need to know so I don't lose my time with that (that was my first thought hence me not looking at that).

Whether an incomplete aspect will become a follow-up ticket is not always known from the beginning:

• Often, issues are identified at QA and we decide that we can live for a while with some of them and it is better to capture these in a separate ticket so that developers can continue to work on other higher priority work and later go back to them. Follow-up tickets in this category cannot be anticipated.
• In some cases, the missing parts were intentionally left by the developers for later (e.g., they were more complex than anticipated or require some framework fixing). For these cases it is indeed useful to communicate those. Capturing them in advance in separate tickets and clarifying the description will help both planning and QA efforts.

Please leave the description with only the things I need to test and put the rest in the follow up tickets.

In this case, I just took a quick look and captured a few issues in separate tickets (listed in T259503#6471483 ), but have not followed the different parts of the description checking them like in a more structured QA process.