The Norwegian Bokmål (`nb_NO`) locale had fallen behind `en_US` by ~55
strings. This brings it up to date.
**Added** translations for the missing keys, including: AI image
generation (`generateImage`, `generating1`–`5`), audio recording
(`allowAudioAccess*`, `noAudio*`, `startAudioRecording`,
`stopAudioRecording`), required meta fields
(`missingRequiredMetaField*`), session recovery (`recoveredAllFiles`,
`recoveredXFiles`, `sessionRestored`), plugin names (`pluginName*`),
image compression (`compressedX`, `compressingImages`), and various UI
strings (`error`, `search`, `pleaseWait`, `unnamed`, `uploadStalled`,
etc.).
**Removed** keys no longer present in `en_US` (`backToSearch`,
`fileSource`, `selectFileNamed`, `timedOut`, `unselectFileNamed`).
**Fixed** `exceedsSize` to include the `%{file}` placeholder, and
aligned key order with `en_US`.
I'm a native Norwegian speaker and reviewed every string. Translation
was done with AI assistance (Claude) and checked by me.
---------
Co-authored-by: Mikael Finstad <finstaden@gmail.com>
- add support for remote uploads
- add support for restore using golden-retriever
- update examples
- #6181 still persists
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Mikael Finstad <finstaden@gmail.com>
right now whenever you upload any file through multipart upload you'll
find empty body returned in `upload-success` event
cause : response from completeMultipartRequest returned in CamelCase
which was not parsed correctly
```xml
<?xml version="1.0" encoding="UTF-8"?>
<CompleteMultipartUploadResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/"><Location>https://testbucketnewfix.s3.eu-north-1.amazonaws.com/13febe01-8d5b-4ed3-bda1-9620fc37c694-VSCode-darwin-universal.dmg</Location><Bucket>testbucketnewfix</Bucket><Key>13febe01-8d5b-4ed3-bda1-9620fc37c694-VSCode-darwin-universal.dmg</Key><ETag>"be4129821e06a893b453f1373995202b-49"</ETag><ChecksumCRC64NVME>Wjr7mcJOfU0=</ChecksumCRC64NVME><ChecksumType>FULL_OBJECT</ChecksumType></CompleteMultipartUploadResult>
```
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
shouldUseMultipart: true was not working due to signature mismatch
AI summary :
This pull request improves support for specifying the `contentType`
during S3 uploads, ensuring that the correct content type is set when
generating presigned URLs for both single and multipart uploads. It also
updates the client-side and server-side code to handle this new
parameter.
**Backend and API enhancements:**
- Updated the `/s3/presign` endpoint in `index.js` to accept an optional
`contentType` parameter and to include it in the S3 `PutObjectCommand`
and `CreateMultipartUploadCommand` requests, defaulting to
`'application/octet-stream'` if not provided.
[[1]](diffhunk://#diff-0c4471088c62917198e1438777b4c7e78fd4d87d450d2a7c78b86b7c647ac97bL360-R360)
[[2]](diffhunk://#diff-0c4471088c62917198e1438777b4c7e78fd4d87d450d2a7c78b86b7c647ac97bR384-R391)
**Client-side and types improvements:**
- Added `contentType` to the `presignableRequest` type to ensure type
safety and clarity when passing this parameter.
- Modified the S3 client (`S3.ts`) to include `contentType` when making
presign requests.
- Updated the example HTML (`rewrite-test.html`) to send `contentType`
in presign requests and enabled multipart uploads for testing.
[[1]](diffhunk://#diff-ca9bc28a71d2d8ac4e0aa6844698f2244594a12e695fc3e153db36674ccb2b52L103-R103)
[[2]](diffhunk://#diff-ca9bc28a71d2d8ac4e0aa6844698f2244594a12e695fc3e153db36674ccb2b52R114)
Cherry-picked as the previous branch got messy ( from last PR )
- XHR-based uploads using `@uppy/utils/fetcher`
- Silent offline detection (without treating it as an error) with
automatic resume ( inspired from old plugin code )
- Retry with backoff using fetcher defaults:
- Max retries: 3
- Delays: 300ms → 600ms → 1200ms
- Retries on 5xx and 429; skips other 4xx errors
- S3 Error Mappings
