Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve i18n for 'Copy to backpack' option in multiselect #43

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

ewpatton
Copy link
Member

Change-Id: I3bf48a801ba9d503692ebdf9450506f9493cc082

Change-Id: I3bf48a801ba9d503692ebdf9450506f9493cc082
@ewpatton ewpatton added the enhancement New feature or request label Feb 29, 2024
@ewpatton ewpatton requested a review from HollowMan6 February 29, 2024 15:26
@ewpatton
Copy link
Member Author

This is a small PR to improve the "Copy to backpack" menu item when multiple blocks are selected. This also allows downstream projects to internationalize the message in a way that makes sense for their projects rather than just sticking the number of blocks on the front.

Copy link
Collaborator

@HollowMan6 HollowMan6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some linting issues here

src/multiselect_contextmenu.js Outdated Show resolved Hide resolved
@ewpatton
Copy link
Member Author

I've defined COPY_X_TO_BACKPACK in our sources as "Add %1 Blocks to Backpack", which I think is more readable than just appending a number to the end. If this message is not defined, then the behavior is the same as the backpack plugin.

@HollowMan6
Copy link
Collaborator

HollowMan6 commented Feb 29, 2024

I've defined COPY_X_TO_BACKPACK in our sources as "Add %1 Blocks to Backpack", which I think is more readable than just appending a number to the end. If this message is not defined, then the behavior is the same as the backpack plugin.

This addition is good, and the fallback is great, but the number appended in the bracket here is the count of blocks in the backpack, not the multi-selected ones, which is also consistent with the default behavior of the backpack plugin: https://github.com/google/blockly-samples/blob/c32266b2b7685c0d4d6646e5bcedb085c435e0b2/plugins/workspace-backpack/src/backpack_helpers.ts#L115

Previously I have the multi-select blocks count at the start of the string.

@ewpatton
Copy link
Member Author

Unfortunately, that convention came from App Inventor and I have never personally been a fan of it. Having the number of blocks in the backpack listed in the menu option is just noise as it has nothing to do with the blocks to which the menu is actually attached. The backpack plugin took this bad design decision from App Inventor. If we have our choice between showing two numbers in this plugin the appropriate number to show would be the number of workable blocks since that's how much the backpack will grow by (which is what is implemented here).

@mark-friedman
Copy link
Contributor

Fwiw, I agree with Evan..

@HollowMan6
Copy link
Collaborator

Okay, actually I don't have preference over these design choices. The core issue I'm focusing on here is consistency. We have to be consistent with the Blockly's backpack plugin, otherwise it will be confusing for users if for some use cases.

Let's assume developers have to init and dispose multi-select plugin back and forth and users may not notice that at all, then we can have:

 return `${Blockly.Msg['COPY_TO_BACKPACK']} (${workableBlocksLength})`;
 return `${Blockly.Msg['COPY_TO_BACKPACK']} (${backpackCount})`;

it's hard for users to determine what the numbers here actually means.

So I think, if you all suggest that we should remove the backpackCount, for sake of consistency, you may want to open a PR there at blockly-samples repo, remove the (${backpackCount}) there, then we can get back to merge this PR. (but lint issues here still needs to be fixed, some lines are too long, check the error with npm run lint).

@mark-friedman
Copy link
Contributor

What if we changed the COPY_TO_BACKPACK message to something like "Copy %1 blocks to backpack". That should make it clear.

@HollowMan6
Copy link
Collaborator

What if we changed the COPY_TO_BACKPACK message to something like "Copy %1 blocks to backpack". That should make it clear.

You mean without using i18n (hardcode) the language or something that is already done by Evan?

I've defined COPY_X_TO_BACKPACK in our sources as "Add %1 Blocks to Backpack", which I think is more readable than just appending a number to the end. If this message is not defined, then the behavior is the same as the backpack plugin.

@ewpatton
Copy link
Member Author

I agree that we should propose a similar change to the backpack plugin. In the meantime I have addressed the linter errors.

Change-Id: Ib28086f505d8911377d1bd827e076dbd715835f6
@mark-friedman
Copy link
Contributor

mark-friedman commented Feb 29, 2024 via email

@HollowMan6
Copy link
Collaborator

I agree that we should propose a similar change to the backpack plugin.

Have we already opened a PR at the blockly-samples repo about this? We can merge this one once we can use the patched backpack plugin version at our side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants