Opened 11 years ago
Closed 5 years ago
#10120 closed defect (patchwelcome)
"Today" not localized in DojoX calendar
Reported by: | davidmark | Owned by: | Shane O'Sullivan |
---|---|---|---|
Priority: | high | Milestone: | 1.13 |
Component: | DojoX Widgets | Version: | 1.4.0b |
Keywords: | calendar localize i18n | Cc: | Tom Trenka, Evan |
Blocked By: | Blocking: |
Description
"Today" is hard-coded in calendar.js at the moment.
Attachments (4)
Change History (14)
Changed 11 years ago by
comment:1 follow-up: 2 Changed 11 years ago by
Cc: | Shane O'Sullivan Tom Trenka Evan added |
---|---|
Keywords: | i18n added |
comment:2 Changed 11 years ago by
Replying to peller:
@DavidMark?: please upload patch files directly without the zip. Was this file UTF-8 encoded? It didn't come up right in my tools, for some reason.
Trac wouldn't take it raw.
dojo/cldr/nls are entirely generated tables (see util/buildscripts/cldr) so you cannot patch them. This would need to be a separate nls table, likely in dojox.widget. Or, for extra credit, I suppose you could pull this string out of the CLDR... it seems to be present in the LDML markup, but some additional logic in the xslt (*cough* ttrenka? *cough*) would be needed to pull it out. This would be the 'right' way to do it, and you'd instantly get translations for dozens of languages, along with 'yesterday' and 'tomorrow'.
Also, you may wish to have an additional substitution string like ${0}: ${1} to render the string, since I suppose that too could be language-specific.
You guys can take it from here... :)
Changed 11 years ago by
Attachment: | Calendar.js added |
---|
Changed 11 years ago by
Attachment: | gregorian.js added |
---|
Changed 11 years ago by
Attachment: | gregorian.2.js added |
---|
comment:3 Changed 11 years ago by
Tortoise SVN's create patch is to blame. Diffs with Japanese characters are unusable.
Only section of the SVN config file that seems remotely relevant:-
# *.c = svn:eol-style=native # *.cpp = svn:eol-style=native # *.h = svn:eol-style=native # *.dsp = svn:eol-style=CRLF # *.dsw = svn:eol-style=CRLF # *.sh = svn:eol-style=native;svn:executable # *.txt = svn:eol-style=native # Makefile = svn:eol-style=native
Uploaded affected files in their entirety.
comment:4 Changed 11 years ago by
You can always use a diff tool. Are you sure both files had valid UTF-8 encoding?
Please note my comment above. We cannot modify gregorian.js directly, since these are generated files, so we cannot use this patch regardless.
comment:5 Changed 11 years ago by
Cc: | Shane O'Sullivan removed |
---|---|
Owner: | changed from dante to Shane O'Sullivan |
comment:6 Changed 11 years ago by
Milestone: | tbd → future |
---|
comment:7 Changed 11 years ago by
I have a working version using dojox/widget/nls, but I'd very much prefer to use the dojo/cldr approach, as it would take care of translating the different locales.
Does anyone know what is involved in doing this? I've looked into the core.zip file, but can't figure out the .dtd file. Trenka, do you know how this works?
comment:8 Changed 11 years ago by
comment:10 Changed 5 years ago by
Milestone: | future → 1.12 |
---|---|
Resolution: | → patchwelcome |
Status: | new → closed |
Given that no one has shown interest in creating a patch in the past 5+ years, I'm closing this as patchwelcome.
@DavidMark?: please upload patch files directly without the zip. Was this file UTF-8 encoded? It didn't come up right in my tools, for some reason.
dojo/cldr/nls are entirely generated tables (see util/buildscripts/cldr) so you cannot patch them. This would need to be a separate nls table, likely in dojox.widget. Or, for extra credit, I suppose you could pull this string out of the CLDR... it seems to be present in the LDML markup, but some additional logic in the xslt (*cough* ttrenka? *cough*) would be needed to pull it out. This would be the 'right' way to do it, and you'd instantly get translations for dozens of languages, along with 'yesterday' and 'tomorrow'.
Also, you may wish to have an additional substitution string like ${0}: ${1} to render the string, since I suppose that too could be language-specific.