Latest translations #3079
Latest translations #3079
Conversation
…glish waiting for final delivery)
rgeraghty
changed the title
|
GET_BUILD |
|
Build successful! 🎉 |
| "startDate": "Start Date", | ||
| "timeZoneName": "time zone", | ||
| "weekday": "day of the week", | ||
| "year": "year" |
There was a problem hiding this comment.
Looks like this one didn't get updated?
There was a problem hiding this comment.
Sorry, missed that one, fixed! I checked others and look good,
| "calendar": "日曆", | ||
| "day": "日", | ||
| "dayPeriod": "上午/下午", | ||
| "dayPeriod": "AM/PM", |
There was a problem hiding this comment.
Both are valid, I checked and found them both used in other project translations, but 上午/下午 is the more common, I've reverted the change, thanks for checking.
| "calendar": "التقويم", | ||
| "day": "يوم", | ||
| "dayPeriod": "ص/م", | ||
| "day": "اليوم", |
There was a problem hiding this comment.
According to google translate, this changed from the arabic word for "day" to "today", which seems different. Similar changes for some other strings here.
For context, these existing translations for field names (e.g. year, month, day, hour, etc.) were imported from Unicode CLDR (we are polyfilling the Intl.DisplayNames API for some browsers), e.g. here. I figured you wouldn't need to re-translate them. Probably the translators were missing some context about where these would be used. Would you recommend we store those externally to these JSON files so they aren't picked up by automation? Should we revert those strings so that they match CLDR (and thus, the native browser API where available)? Sorry this probably ended up being a bunch of extra work...
There was a problem hiding this comment.
@devongovett this Is a bit tricky, as translation automation will end up replacing any existing translation from GIT with translations from our backend 'glaas' database, with is what translator uses. Any direct GIT translation would eventually get replaced, and up to that translator.
CLDR is the perfect standard, let me check to update our backend to use the original translation, which would fix this issue for now (and revert back a number of changes), I'll check and get back to you. Translations should not change again, unless someone reports a JIRA requesting the translation be changed, then translator would update glass.
CLDR does have translation files that can be used and may be better long term solution, use those and not pass through our system, for now through I'll check and revert ones I can, I'll give update later today or morning
…kend glaas, so no change in future updates
| "hour": "sat", | ||
| "minute": "minut", | ||
| "month": "mesec", | ||
| "second": "sekund", |
There was a problem hiding this comment.
Looks like this one changed. I guess something about Serbian written in the Latin alphabet vs Cyrillic? Probably ok.
There was a problem hiding this comment.
Though I just checked and
new Intl.DisplayNames('sr-SP', {type: 'dateTimeField'}).of('day')
// => 'дан'There was a problem hiding this comment.
yeah this is support to be Latin based, one we standard support from Adobe translations, but code itself frequently causes issues,
There was a problem hiding this comment.
I'm checking this more with our team, will followup
There was a problem hiding this comment.
@devongovett I reverted the API related strings back for now,
|
@devongovett I've updated for comments above, no more changes planned, please let me know if anything else, and we can review locale support separately, (related to sr-SP above) |
devongovett
left a comment
devongovett
left a comment
There was a problem hiding this comment.
Looks good. Thanks again for going back and forth on this. 😄
4 participants
Latest translations for React-Spectrum, for all new strings as well as general linguistic bug fixing
PR is complete and ready to merge if looks okay,