-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
fix(files): conversion api simplification and conflict check #50208
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
Conversation
juliusknorr
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good and works as expected now with and without passing a destination to the OCS endpoint
| * @param string $extension The file extension for the target MIME type (e.g. 'png') | ||
| * @param string $displayName The human-readable name of the target MIME type (e.g. 'Image (.png)') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO the translations should omit the extension, as we can build this string ourselves using the provided extension.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about this, I don't know how flexible we want to make it.
Do we ALWAYS want to show the (.png) part ?
cc @marcoambrosini @nimishavijay
for context, this would be visible in the Save as submenu,

Entries would be like this
Image (.jpg)Image (.png)Image (.gif)
Maybe we should directly use more human text like this? Then we can omit the extension alltogether?
Jpeg imagePng imageGif image
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, for example Windows doesn't even display the file extensions anymore, so they could be meaningless to many users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my perspective It makes little difference and I'd be fine with both approaches
3687728 to
85bea72
Compare
|
@provokateurin maybe we can tackle the l10n on a followup once we have an answer from the design team? :) |
85bea72 to
fdd2b77
Compare
provokateurin
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good, but unfortunately you need to fix the depencencies 🙈
fdd2b77 to
55337af
Compare
4271705 to
27d2fff
Compare
Signed-off-by: skjnldsv <[email protected]>
1652349 to
8e6c399
Compare
Signed-off-by: skjnldsv <[email protected]>
8e6c399 to
19ce362
Compare
Followup #49922