Hawaiian Diacritical Marks and Other Special Characters
You can insert special characters into a web page by typing an ampersand, a number or letter sequence, and a semicolon.
These are the codes for rendering diacritical marks in Hawaiian words:
ʻ — ʻokina or glottal stop
Ā — Ā
ā — ā
Ē — Ē
ē — ē
Ī — Ī
ī — ī
Ō — Ō
ō — ō
Ū — Ū
ū — ū
Other frequently used codes:
& — ampersand (because the ampersand is an "escape character", this is the safest way to display an actual ampersand)
– — n-width dash
— — m-width dash
¢ — ¢
— non-breaking space (used between words you don't want separated at line breaks)
A Note on Accessibility: The ʻokina is known to throw off screen reading programs that read out text for blind people. To address this, University of Hawaiʻi Office of Communications recommends using the aria-label attribute within a span tag to supply the word (without diacrical marks) to the screen reader.
Yes, I have a family that just started that have č and ū in their last names. We've been able to support all the families with accent letters until now.
We have been copying and pasting accented names from emails into student records. However, our students from Vietnam that have an ồ in their name turns into a ? question mark.
Rather then starting another idea, I would like to piggy-back on this one. When a new family is accepted and an account is created in Tuition Manager, the transfer of data should include the correct accent, tilda and umlaut characters. TM does not even support the copy and paste functionality that Core has.
We would like to be able to use accents everywhere - in assignment titles, as well. Currently if our French teacher types "passé" it shows up as "passé".
Since I spent over an hour with Blackbaud Support working out an import failure, I thought I'd share a workaround to Blackbaud's import failures when accents are involved. I've also noted this on https://blackbaudk12.ideas.aha.io/ideas/K12CO-I-284.
Blackbaud's undocumented encoding (both for import and export) is ISO-8859-1; Windows' ANSI encoding is an offshoot of ISO-8859-1, and the encoding is known by other names as well.
Note that Google Sheets (at least on a Mac) defaults to UTF-8 encoding, so an export from Google Sheets will need to have its encoding changed to ISO-8859-1.
IMPORT TO BLACKBAUD
From Windows:
Open your CSV file in Notepad, which will automatically detect the correct encoding, unlike Excel);
Select "File > Save as..."
At the bottom, where the "Encoding" drop down is, select "ANSI" (this is Microsoft's ISO-8859-1, and seems close enough to be usable)
Either save over the existing file or enter a new name, make sure your File Type is "All Files", include your .CSV extension and save it as a new file
Upload to Blackbaud for import (and hope they haven't changed the format or messed it up in a novel fashion)
From macOS:
Open Terminal
Run the following command: iconv -t ISO-8859-1 {your CSV filename and path} > {new CSV filename and path}
Upload to Blackbaud for import (and hope they haven't changed the format or messed it up in a novel fashion)
EXPORT FROM BLACKBAUD
On a Windows system, you shouldn't have to do anything; Blackbaud's standard encoding should work just fine.
If you want to import into Google Sheets, Blackbaud's standard encoding also works...because Google Sheets checks the encoding of the file before importing it.
On a macOS system, Numbers will also auto-detect the encoding properly.
With Excel for Mac:
Open an empty spreadsheet file
Select "File > Import"
Select "CSV", then click "Import"
Locate and double-click the Blackbaud export file
At "Text Import Wizard - Step 1 of 3", select "File origin: Windows (ANSI), then click Next NOTE:Western (ISO Latin 1) or Western (Windows Latin 1) will also work; however, "Macintosh" will NOT...and of course it can't auto-detect.
At "Text Import Wizard - Step 2 of 3", select "Delimiters: Comma and click FinishOR click Next and make any additional changes in "Text Import Wizard - Step 3 of 3", then click Finish
With Terminal:
Open Terminal
Run the following command: iconv -t UTF-8 {blackbaud's CSV filename and path} > {UTF-8 CSV filename and path}
Profit!
Credit to Stack Exchange, which provided many many clues to lead me to this solution.
Additionally, ensuring consistency across the system is important. For instance, we have a kid with a "ñ" in his name. Looking in any SKY list requires the use of the "ñ" but in data imports, you must use "n". The "ñ" should work everywhere.
Please please please allow us to use special characters! We have current families that are very upset that these cannot display for them. They feel that it is against their heritage to have it show without the accent.
I have found that there is a work-around for this. If you cut and past the name with the special characters from Word (or another document that allows for the special characters) the system will take them and display them correctly. There are a few instances, however, that they do not appear correctly (for instance when you run a list).
An additional comment about "special characters" - There are many accents in family names that are not "special characters" any more than the apostrophe is in O'Keefe or O'Reilly. It is an integral part of the name. And in an increasingly diverse world and at schools with international students, it is important that names be spelled correctly.
Hawaiian, along with English, is an official language of the US state of Hawaiʻi.
https://www2.hawaii.edu/~rtoyama/pubs/diacritics.html
Hawaiian Diacritical Marks and Other Special Characters
You can insert special characters into a web page by typing an ampersand, a number or letter sequence, and a semicolon.
These are the codes for rendering diacritical marks in Hawaiian words:
ʻ — ʻokina or glottal stop
Ā — Ā
ā — ā
Ē — Ē
ē — ē
Ī — Ī
ī — ī
Ō — Ō
ō — ō
Ū — Ū
ū — ū
Other frequently used codes:
& — ampersand (because the ampersand is an "escape character", this is the safest way to display an actual ampersand)
– — n-width dash
— — m-width dash
¢ — ¢
— non-breaking space (used between words you don't want separated at line breaks)
A Note on Accessibility: The ʻokina is known to throw off screen reading programs that read out text for blind people. To address this, University of Hawaiʻi Office of Communications recommends using the aria-label attribute within a span tag to supply the word (without diacrical marks) to the screen reader.
Yes, I have a family that just started that have č and ū in their last names. We've been able to support all the families with accent letters until now.
I concur with Jim Robb "With an ever widening diverse population, we as schools need to respect the cultures and languages of the customer."
We have been copying and pasting accented names from emails into student records. However, our students from Vietnam that have an ồ in their name turns into a ? question mark.
+1 on allowing different file formats on imports - mac based shop here TY!!
Rather then starting another idea, I would like to piggy-back on this one. When a new family is accepted and an account is created in Tuition Manager, the transfer of data should include the correct accent, tilda and umlaut characters. TM does not even support the copy and paste functionality that Core has.
We would like to be able to use accents everywhere - in assignment titles, as well. Currently if our French teacher types "passé" it shows up as "passé".
Since I spent over an hour with Blackbaud Support working out an import failure, I thought I'd share a workaround to Blackbaud's import failures when accents are involved. I've also noted this on https://blackbaudk12.ideas.aha.io/ideas/K12CO-I-284.
Blackbaud's undocumented encoding (both for import and export) is ISO-8859-1; Windows' ANSI encoding is an offshoot of ISO-8859-1, and the encoding is known by other names as well.
Note that Google Sheets (at least on a Mac) defaults to UTF-8 encoding, so an export from Google Sheets will need to have its encoding changed to ISO-8859-1.
IMPORT TO BLACKBAUD
From Windows:
Open your CSV file in Notepad, which will automatically detect the correct encoding, unlike Excel);
Select "File > Save as..."
At the bottom, where the "Encoding" drop down is, select "ANSI" (this is Microsoft's ISO-8859-1, and seems close enough to be usable)
Either save over the existing file or enter a new name, make sure your File Type is "All Files", include your .CSV extension and save it as a new file
Upload to Blackbaud for import (and hope they haven't changed the format or messed it up in a novel fashion)
From macOS:
Open Terminal
Run the following command:
iconv -t ISO-8859-1 {your CSV filename and path} > {new CSV filename and path}
Upload to Blackbaud for import (and hope they haven't changed the format or messed it up in a novel fashion)
EXPORT FROM BLACKBAUD
On a Windows system, you shouldn't have to do anything; Blackbaud's standard encoding should work just fine.
If you want to import into Google Sheets, Blackbaud's standard encoding also works...because Google Sheets checks the encoding of the file before importing it.
On a macOS system, Numbers will also auto-detect the encoding properly.
With Excel for Mac:
Open an empty spreadsheet file
Select "File > Import"
Select "CSV", then click "Import"
Locate and double-click the Blackbaud export file
At "Text Import Wizard - Step 1 of 3", select "File origin:
Windows (ANSI)
, then click NextNOTE:
Western (ISO Latin 1)
orWestern (Windows Latin 1)
will also work; however, "Macintosh" will NOT...and of course it can't auto-detect.At "Text Import Wizard - Step 2 of 3", select "Delimiters:
Comma
and click Finish OR click Next and make any additional changes in "Text Import Wizard - Step 3 of 3", then click FinishWith Terminal:
Open Terminal
Run the following command:
iconv -t UTF-8 {blackbaud's CSV filename and path} > {UTF-8 CSV filename and path}
Profit!
Credit to Stack Exchange, which provided many many clues to lead me to this solution.
Additionally, ensuring consistency across the system is important. For instance, we have a kid with a "ñ" in his name. Looking in any SKY list requires the use of the "ñ" but in data imports, you must use "n". The "ñ" should work everywhere.
Please please please allow us to use special characters! We have current families that are very upset that these cannot display for them. They feel that it is against their heritage to have it show without the accent.
I agree. With an ever widening diverse population, we as schools need to respect the cultures and languages of the customer.
I have found that there is a work-around for this. If you cut and past the name with the special characters from Word (or another document that allows for the special characters) the system will take them and display them correctly. There are a few instances, however, that they do not appear correctly (for instance when you run a list).
An additional comment about "special characters" - There are many accents in family names that are not "special characters" any more than the apostrophe is in O'Keefe or O'Reilly. It is an integral part of the name. And in an increasingly diverse world and at schools with international students, it is important that names be spelled correctly.