[$500] Assign Task - Task completion and reopening notification not translated in Share Somewhere section

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Click on the plus sign and select "Assign Tasks".
2. Add a title, assignee, and share somewhere, then confirm the task.
3. Go to settings > preference > change language to Spanish.
4. Click on the plus sign again and select "Assign Tasks" > Title > Search for the email you assigned the task to in the Share Somewhere section

Expected Result:

The task completion and reopening notification should be translated in the Share Somewhere section as per user preference, just like in LHN and Assigned Task

Actual Result:

The task completion and reopening notification are not translated in the Share Somewhere section, causing inconsistency in language usage

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• Windows / Chrome
• MacOS / Desktop

Version Number: 1.3.56-0

Reproducible in staging?: Yes

Reproducible in production?: Yes

If this was caught during regression testing, add the test name, ID and link from TestRail:

Email or phone of affected tester (no customers):

Logs: https://stackoverflow.com/c/expensify/questions/4856

Notes/Photos/Videos: Any additional supporting documentation

screen-capture.-.2023-08-11T101123.220.mp4

Recording.2945.mp4

Expensify/Expensify Issue URL:

Issue reported by: @tewodrosGirmaA

Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1691775469383549

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~016eac5381208cd4cb
• Upwork Job ID: 1698533354550611968
• Last Price Increase: 2023-09-11

[DylanDylann]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Task completion and reopening notification not translated in Share Somewhere section

What is the root cause of that problem?

The translation for complete task and re-open task work well in LHN because we have logic to update alternativeText in getOptionData for LHN options

App/src/libs/SidebarUtils.js

Lines 300 to 304 in 08b75f3

	} else if (lodashGet(lastAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.TASKREOPENED) {
	result.alternateText = `${Localize.translate(preferredLocale, 'task.messages.reopened')}: ${report.reportName}`;
	} else if (lodashGet(lastAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.TASKCOMPLETED) {
	result.alternateText = `${Localize.translate(preferredLocale, 'task.messages.completed')}: ${report.reportName}`;
	} else {

But when creating option for share destination, we don't have any logic to update the translation like we did in LHN

What changes do you think we should make in order to solve the problem?

I suggest that when creating option for share destination, we should update translation if the last actionName is complete task or reopen task (It seems we miss translate cancelled task message in LHN)

1. we need to translate cancelled task in LHN

App/src/libs/SidebarUtils.js

Lines 300 to 304 in 08b75f3

	} else if (lodashGet(lastAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.TASKREOPENED) {
	result.alternateText = `${Localize.translate(preferredLocale, 'task.messages.reopened')}: ${report.reportName}`;
	} else if (lodashGet(lastAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.TASKCOMPLETED) {
	result.alternateText = `${Localize.translate(preferredLocale, 'task.messages.completed')}: ${report.reportName}`;
	} else {

add condition:

else if (lodashGet(lastAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.TASKCANCELLED) {
                result.alternateText = `${Localize.translate(preferredLocale, 'task.messages.canceled')}: ${report.reportName}`;
            }

2. Update complete task, reopen task and cancel task in share destination options
   In here:

   App/src/libs/OptionsListUtils.js

   Line 505 in 08b75f3

   if (result.isChatRoom || result.isPolicyExpenseChat) {

   
   we should add

if ((result.isChatRoom || result.isPolicyExpenseChat || result.isThread || result.isTaskReport)) {
            const lastAction = visibleReportActionItems[report.reportID];
            if (lodashGet(lastAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.RENAMED) {
                const newName = lodashGet(lastAction, 'originalMessage.newName', '');
                result.alternateText = Localize.translate(preferredLocale, 'newRoomPage.roomRenamedTo', {newName});
            } else if (lodashGet(lastAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.TASKREOPENED) {
                result.alternateText = `${Localize.translate(preferredLocale, 'task.messages.reopened')}: ${report.reportName}`;
            } else if (lodashGet(lastAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.TASKCOMPLETED) {
                result.alternateText = `${Localize.translate(preferredLocale, 'task.messages.completed')}: ${report.reportName}`;
            } else if (lodashGet(lastAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.TASKCANCELLED) {
                result.alternateText = `${Localize.translate(preferredLocale, 'task.messages.canceled')}: ${report.reportName}`;
            }
}

With this approach, we need to define visibleReportActionItems as we did in SidebarUtils.
We also can consider to create utils function to update alternative text to avoid duplicated code

Result

[esh-g]

Proposal

Please re-state the problem we are trying to fix

For task reports, actions like reopening and completing are not translated to Spanish in share options but are translated in LHN, therefore, an inconsistency.

Disclaimer: This proposal is a little lengthy because I went into a lot of detail for the explanation please be sure to ask about any part that might be doubtful, I will be happy to explain it further.

What is the root cause of the problem?

When creating the options to display in RHP, we are using the report.lastMessageText property which (for task actions like opening and reopening) is always in English. So, how are they translated in the LHN then? Well it's because we explicitly translate them in SideBarUtils.js:

App/src/libs/SidebarUtils.js

Lines 297 to 308 in aaa12f4

	if ((result.isChatRoom || result.isPolicyExpenseChat || result.isThread || result.isTaskReport) && !result.isArchivedRoom) {
	const lastAction = visibleReportActionItems[report.reportID];
	if (lodashGet(lastAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.RENAMED) {
	const newName = lodashGet(lastAction, 'originalMessage.newName', '');
	result.alternateText = Localize.translate(preferredLocale, 'newRoomPage.roomRenamedTo', {newName});
	} else if (lodashGet(lastAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.TASKREOPENED) {
	result.alternateText = `${Localize.translate(preferredLocale, 'task.messages.reopened')}: ${report.reportName}`;
	} else if (lodashGet(lastAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.TASKCOMPLETED) {
	result.alternateText = `${Localize.translate(preferredLocale, 'task.messages.completed')}: ${report.reportName}`;
	} else {
	result.alternateText = lastMessageTextFromReport.length > 0 ? lastMessageText : Localize.translate(preferredLocale, 'report.noActivityYet');
	}

But this translation is not happening when we create options to share because that uses the method getLastMessageTextForReport, which in-turn returns the report.lastMessageText

App/src/libs/OptionsListUtils.js

Line 490 in 38ed41f

const lastMessageTextFromReport = getLastMessageTextForReport(report);

What changes should we make in-order to solve this?

We should stop the differential use of the lastMessageText because even in sideBarUtils.js we are using getLastMessageTextForReport() and then the translations are made after that. But what we should be doing is making the translations in the getLastMessageTextForReport() function itself which would therefore mean moving the translation logic into getLastMessageTextForReport() and along the way, make some optimisations to the function as well.

So after moving that logic, this is how the getLastMessageTextForReport() function should look like:

function getLastMessageTextForReport(report) {
    const lastReportAction = _.find(
        allSortedReportActions[report.reportID],
        (reportAction, key) => ReportActionUtils.shouldReportActionBeVisible(reportAction, key) && reportAction.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
    );

    let lastMessageTextFromReport = report ? report.lastMessageText || '' : '';
    const lastNonWhisper = _.find(allSortedReportActions[report.reportID], (action) => !ReportActionUtils.isWhisperAction(action)) || {};

    if (ReportUtils.isReportMessageAttachment({text: report.lastMessageText, html: report.lastMessageHtml, translationKey: report.lastMessageTranslationKey})) {
        lastMessageTextFromReport = `[${Localize.translateLocal(report.lastMessageTranslationKey || 'common.attachment')}]`;
    } else if (ReportActionUtils.isReportPreviewAction(lastReportAction)) {
        const iouReport = ReportUtils.getReport(ReportActionUtils.getIOUReportIDFromReportActionPreview(lastReportAction));
        lastMessageTextFromReport = ReportUtils.getReportPreviewMessage(iouReport, lastReportAction);
    } else if (ReportActionUtils.isModifiedExpenseAction(lastReportAction)) {
        lastMessageTextFromReport = ReportUtils.getModifiedExpenseMessage(lastReportAction);
    } else if (ReportActionUtils.isPendingRemove(lastNonWhisper)) {
        const latestVisibleAction =
            _.find(
                allSortedReportActions[report.reportID],
                (action) => ReportActionUtils.shouldReportActionBeVisibleAsLastAction(action) && !ReportActionUtils.isCreatedAction(action),
            ) || {};
        lastMessageTextFromReport = lodashGet(latestVisibleAction, 'message[0].text', '');
    } else if (ReportUtils.isChatRoom(report) || ReportUtils.isThread(report) || ReportUtils.isPolicyExpenseChat(report) || ReportUtils.isTaskReport(report)) {
        if (lodashGet(lastReportAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.RENAMED) {
            const newName = lodashGet(lastReportAction, 'originalMessage.newName', '');
            lastMessageTextFromReport = Localize.translate(preferredLocale, 'newRoomPage.roomRenamedTo', {newName});
        } else if (lodashGet(lastReportAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.TASKREOPENED) {
            lastMessageTextFromReport = `${Localize.translate(preferredLocale, 'task.messages.reopened')}: ${report.reportName}`;
        } else if (lodashGet(lastReportAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.TASKCOMPLETED) {
            lastMessageTextFromReport = `${Localize.translate(preferredLocale, 'task.messages.completed')}: ${report.reportName}`;
        } else if (lodashGet(lastReportAction, 'actionName', '') === CONST.REPORT.ACTIONS.TYPE.TASKCANCELLED) {
            lastMessageTextFromReport = `${Localize.translate(preferredLocale, 'task.messages.canceled')}: ${report.reportName}`;
        } else {
            lastMessageTextFromReport = lastMessageTextFromReport.length > 0 ? lastMessageTextFromReport : Localize.translate(preferredLocale, 'report.noActivityYet');
        }
    }
    return lastMessageTextFromReport;
}

This might look like a lot of changes, so here is a summary of them:

1. The default value of the lastMessageTextFromReport is moved from the else part to the top during the declaration of the variable itself.
   

   App/src/libs/OptionsListUtils.js

   Lines 390 to 392 in 2e8e699

   	} else {
   	lastMessageTextFromReport = report ? report.lastMessageText || '' : '';

2. The whisper moderation logic mas been moved out of the else block since the default value of lastMessageTextFromReport is already set beforehand.
3. The translation logic from sideBarUtils.js has been added as the last condition.
4. A translation for CONST.REPORT.ACTIONS.TYPE.TASKCANCELLED has also been added which was not present in the sideBarUtils.js before.

This function now looks much cleaner than before and all the translation logic is also now at once place. Now, in SideBarUtils.js, the else condition after the translation should still remain. Therefore, the if-else block can be removed and only the following code spared:

if (!lastMessageText) {
        // Here we get the beginning of chat history message and append the display name for each user, adding pronouns if there are any.
        // We also add a fullstop after the final name, the word "and" before the final name and commas between all previous names.
        lastMessageText =
            Localize.translate(preferredLocale, 'reportActionsView.beginningOfChatHistory') +
            _.map(displayNamesWithTooltips, ({displayName, pronouns}, index) => {
                const formattedText = _.isEmpty(pronouns) ? displayName : `${displayName} (${pronouns})`;

                if (index === displayNamesWithTooltips.length - 1) {
                    return `${formattedText}.`;
                }
                if (index === displayNamesWithTooltips.length - 2) {
                    return `${formattedText} ${Localize.translate(preferredLocale, 'common.and')}`;
                }
                if (index < displayNamesWithTooltips.length - 2) {
                    return `${formattedText},`;
                }
            }).join(' ');
    }

    result.alternateText = lastMessageText || formattedLogin;

This code makes sure that we have No activity Yet text and This is the beginning of your chat... in the appropriate places.

[melvin-bot]

Triggered auto assignment to @mallenexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[melvin-bot]

@mallenexpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot]

@mallenexpensify 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

[mallenexpensify]

From what I can see in my tests, if the task was originally created in English, we leave it that way and don't update it.

1. Is that true?
2. If so, is the bug or feature request to change historical data in chats from English to Spanish?

cc @tewodrosGirmaA who reported the issue

[DylanDylann]

@mallenexpensify

If report action is reopened task message, the actionName is TASKREOPENED
If report action is completed task message, the actionName is TASKCOMPLETED
If report action is cancelled task message, the actionName is TASKCANCELLED
If report action is created task message (like "Assigned a task ..."), the actionName is CREATED

As I see that if the last message is TASKREOPENED, TASKCOMPLETED we will translate it in LHN (It seems that we missed TASKCANCELLED) because we can realize it by actionName of last report action. And we don't translate if the last message is "Assigned a task ..." because there is no way to know if it is a created task message. If we want to translate "Assigned a task ..." we need to introduce new actionName for created task message with the change from BE

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~016eac5381208cd4cb

[melvin-bot]

Triggered auto assignment to @slafortune (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @Ollyws (External)

[mallenexpensify]

Thanks @DylanDylann . @Ollyws , can you please review @DylanDylann 's comment above #25633 (comment)

Then, if you agree, can you please review their proposal above? Thx

@slafortune I'm off this week, can you please keep 👀 on this then I'll snag it back on Monday? Thx

[melvin-bot]

@Ollyws @slafortune @mallenexpensify this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[slafortune]

It looks like we need some backend work done if this is something we will move forward with -

If we want to translate "Assigned a task ..." we need to introduce new actionName for created task message with the change from BE

Adding engineering

[melvin-bot]

Triggered auto assignment to @AndrewGable (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[slafortune]

Removing myself since @mallenexpensify will be back next week and I'm out on sabbatical.

[melvin-bot]

@AndrewGable @Ollyws @mallenexpensify this issue is now 4 weeks old and preventing us from maintaining WAQ, can you:

• Decide whether any proposals currently meet our guidelines and can be approved as-is today
• If no proposals meet that standard, please take this issue internal and treat it as one of your highest priorities
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[melvin-bot]

Current assignee @Ollyws is eligible for the Internal assigner, not assigning anyone new.

[AndrewGable]

@marcochavezf or @thienlnam - I'd be curious for your thoughts on how we should best handle this and if any of the existing solutions make sense.

I think the current discussion on whether we should do this translation on the front end or back end has probably been discussed previously and you might have some examples that will help us come to the correct decision in this case. Thank you!

[DylanDylann]

For more information, currently from the FE side, we only support translating 3 cases:
the actionName is TASKREOPENED
the actionName is TASKCOMPLETED
the actionName is TASKCANCELLED

From FE, We don't support translating:

1. Created a task:
2. Assigned a task to

[thienlnam]

There have been a few issues related to translation issues - we've largely decided to close them until we support localization in the backend as these are messages stored in the reportAction message itself

[DylanDylann]

@thienlnam Currently, we are supporting translating 3 cases:
the actionName is TASKREOPENED
the actionName is TASKCOMPLETED
the actionName is TASKCANCELLED

in reportAction message, LHN. So I think we also should support translating these cases in share somewhere section for consistency.

we support localization in the backend

It means all task message will be translated from BE? and we will remove all translation for task message in FE, right?

[AndrewGable]

Sounds like yes we should close this and when we move the translation to the backend we will remove the front end translation.

@thienlnam - Should we be linking this case to a larger tracking issue?

[thienlnam]

BE localization is a pretty far out project - I imagine when we start to support that we'll go through and address all existing cases we have now. I don't think there is a tracking issue though

[DylanDylann]

I don't think this consistency is acceptable in the long time. It might confuse for user when with the same system message some places translate, some don't translate

[esh-g]

@thienlnam I would ask you to once go through my proposal before deciding because in it, I have proposed to move the translation logic to getLastMessageTextForReport() and removing it from it's current place. Therefore, no new logic is being added and the getLastMessageTextForReport() is refactored to not include the "ugly" code as mentioned in a comment in that function.

App/src/libs/OptionsListUtils.js

Lines 392 to 395 in 2e8e699

	// Yeah this is a bit ugly. If the latest report action that is not a whisper has been moderated as pending remove
	// then set the last message text to the text of the latest visible action that is not a whisper or the report creation message.
	const lastNonWhisper = _.find(allSortedReportActions[report.reportID], (action) => !ReportActionUtils.isWhisperAction(action)) || {};

[melvin-bot]

@AndrewGable, @Ollyws, @mallenexpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!

[mallenexpensify]

I'm unsure what the next best step is here. Should we put this on hold pending backend localization? (then link to the tracking issue once it's created?)

[AndrewGable]

Sounds like @thienlnam is saying we should not do a work around and should handle this via the API/back end. There is a question of when this will happen, but we don't know for now. So I'd close this and we can circle back on this via the API at a later date.

[mallenexpensify]

Thanks @AndrewGable !!

[tewodrosGirmaA]

@mallenexpensify am I eligible for payment ?

[mallenexpensify]

@tewodrosGirmaA from CONTRIBUTING.md

If it's a valid bug that we choose to resolve by deploying it to production — either internally or via an external contributor — then we will compensate you $50 for identifying the bug

Since we didn't fix anything here yet, compensation is not due.
The other consideration is, if this is already something we had planned to address at some point, then compensation isn't due. This can be a lil tricky though because we won't always have something to point to to show proof. It's also rare and doesn't happen that often.

[tewodrosGirmaA]

@mallenexpensify OK Thank you for Replying, No problem , I understand 😊