Change xs:string to internationalizedText as appropriate

[cjerdonek]

This issue is to change "xs:string" to "internationalizedText" as appropriate.

This is something that I believe was done in one of the earlier PR's, but then got lost. I can take care of this by reviewing the old comments and PR's, and then create a new PR. I will wait until after the style stuff is done before making the PR.

[cjerdonek]

I started working on this in branch feature/issue-77-internationalized-text.

Also, here are the elements to update from the issue #39 comments:

ballot_response.txt:

• text (doesn't exist; did BallotSelectionType.Selection)

candidate.txt:

• party (doesn't exist; see Party.Name)
• biography (doesn't exist?)

contest.txt:

• primary party (did Party.Name)
• electorate_specifications
• office (did Office.Name)

custom_ballot.txt:

• heading (doesn't exist?)

early_vote_site.txt: (doesn't exist?)

• directions (see PollingLocation.Directions)
• voter_services (did ElectionAdministration.VoterServices instead)
• days_times_open (did ElectionAdministration.Hours instead)

election.txt:

• registration_info
• absentee_ballot_info

election_official.txt:

• title

polling_location.txt:

• directions

referendum.txt: (became BallotMeasureContest)

• title (did ContestType.BallotTitle)
• subtitle (did ContestType.BallotTitle)
• brief (became SummaryText)
• text (became FullText)
• pro_statement
• con_statement
• passage_threshold
• effect_of_abstain

source.txt:

• description

election.txt:

• name (doesn't exist?)
• election_type

party.txt:

• name

[cjerdonek]

@demcg Yes, I included Candidate.BallotName for that reason. Thanks. I'm in the process of typing up some thoughts about this issue and others.

[cjerdonek]

Okay, I created PR #92 to address this.

I think the PR takes care of a lot of the easy and/or obvious stuff, but I think it would be good to start thinking about a more careful approach and rules around this going forward.

Here are some thoughts to consider around this, to give you an idea:

1. I think it might be important to develop and somehow maintain a clear distinction between element values that are (a) potentially for human-readability by voters, and (b) values that are for "internal" use only (e.g. enums). This distinction is perhaps the determining factor in whether something should be internationalized. This also means that in cases where we are currently using a string for both purposes (i.e. both display and internally), it might make sense to separate those two responsibilities and have different elements for the two purposes.
2. I think there is a good chance that even proper nouns would need to be internationalized, for the reason that @demcg mentioned. Things like election officials' names, street addresses, city, and state are all things to consider here.
3. Similar to (2), are there cases where numbers might need to be internationalized, or can arabic numbers be used for all languages?
4. For proper nouns that need to be internationalized, there is the question of whether such translations can be generated automatically via transliteration (i.e. letter by letter), or if they need to be manually specified. For example, I think in SF, candidates are allowed to provide a "custom" Chinese name. But maybe that is an exceptional case. If certain types of element values should really be transliterated (e.g. an election official's name), maybe that's a candidate for an additional string type. For these strings, counties would not need to provide translations of those elements (because it could be done automatically downstream by VIP, etc), yet multi-lingual voters would still benefit because the strings would wind up translated in the final product.
5. One thing we haven't thought about but that might be necessary at some point is the use of "format strings" to internationalize certain types of information. For example, to translate "DISTRICT X" into Chinese, it doesn't suffice to translate "District" and then follow that by the number. DISTRICT X translates to 第X選區 (with the X in the middle).

[demcg]

I erased my comment because I found the Candidate.BallotName, but for completeness I will include the image that was in the comment

[cjerdonek]

Closed by PR #92.

[jungshadow]

@cjerdonek All excellent points.

I think there is a good chance that even proper nouns would need to be internationalized, for the reason that @demcg mentioned. Things like election officials' names, street addresses, city, and state are all things to consider here.

True, but I think this is a solid start and probably needs some additional input from other states/localities on whether this is something that should be consolidated under a "display" field or should be "built" by the end user.

Similar to (2), are there cases where numbers might need to be internationalized, or can arabic numbers be used for all languages?

Anecdotally, I know there are a lot of non-latin languages that, while there is a separate numeric system, using Arabic numbers is accepted. We'll still need to gather more data on the needs of local communities in more places.

For proper nouns that need to be internationalized, there is the question of whether such translations can be generated automatically via transliteration (i.e. letter by letter), or if they need to be manually specified.

Again, I think we'll need broader feedback here.

One thing we haven't thought about but that might be necessary at some point is the use of "format strings" to internationalize certain types of information. For example, to translate "DISTRICT X" into Chinese, it doesn't suffice to translate "District" and then follow that by the number. DISTRICT X translates to 第X選區 (with the X in the middle).

Interesting. This probably does need it's own display field, but I think what we have is solid for now.

At some point, I imagine we'll get into a very interesting "unwritten languages" discussion :)

[cjerdonek]

Thanks, @jungshadow. And yes, to be clear, my comment was meant as food for thought for the future as opposed to a suggestion to do something more about it now.