Skip to content

Conversation

@manics
Copy link
Member

@manics manics commented Feb 3, 2013

To test: find a system where ./build.py build-all-dev fails in the test-compile target due to a charset encoding error. This should fix it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

\u00F6 is also an option

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As long as we're consistent everywhere.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, given how easy it seems to be to mess up encodings in source and how different viewing applications seem to cope differently (at least on the Mac), maybe we should be using escaped codepoints everywhere, yes. What do you think? I could file a ticket about fixing the other instances and fix the others I notice in the meantime. (I had already fixed mine in mtbc@7b77a74 -- I assume there's some convenient tool into which one can paste the strings to get their escaped equivalents.)

@manics
Copy link
Member Author

manics commented Feb 4, 2013

maybe we should be using escaped codepoints everywhere, yes. What do you think? I could file a ticket about fixing the other instances and fix the others I notice in the meantime.

That sounds like the most foolproof option, unless we add localisation for non-ascii languages. I've changed ö to \u00F6

@mtbc
Copy link
Member

mtbc commented Feb 4, 2013

Great, good to merge, thanks.

@mtbc
Copy link
Member

mtbc commented Feb 4, 2013

@joshmoore
Copy link
Member

Would there be a way to detect (via setting a property in ant, etc) that non-UTF-8 extended characters/encodings are in a file? If so, I'm personally for our allowing UTF-8 to be used directly. Java is UTF8 safe and so having them in the files makes sense. But if we can't do it carefully, then I'll have to learn to live with escapes.

/cc @jburel, thoughts?

@mtbc
Copy link
Member

mtbc commented Feb 4, 2013

Yes, if we could rely on our viewers and editors not to do something dumb, it'd be great to omit escapes, but I think first we'd have to figure out how the mistakes are happening and issue guidance to prevent further occurrences: for instance, perhaps by changing the text encoding setting in Eclipse's General -> Workspace preferences setting, which starts out as MacRoman.

@manics
Copy link
Member Author

manics commented Feb 4, 2013

You could always run this over every file during the build (which would help catch anything in non-Java files too): https://gist.github.com/4707338

@jburel
Copy link
Member

jburel commented Feb 4, 2013

I have used encoding like \u2103 for (DEGREE CELSIUS). I am all for unifying and use UTF-8. We will need to add info to our documentation of what is expected.

@jburel
Copy link
Member

jburel commented Feb 4, 2013

The following could be used as a ref http://www.fileformat.info/info/unicode/index.htm

@mtbc
Copy link
Member

mtbc commented Feb 5, 2013

Documentation: absolutely. If we decide to use unescaped characters, then once other developers see that then they may be more likely to attempt it themselves! (-:

@manics
Copy link
Member Author

manics commented Feb 5, 2013

Switched back to ö

@mtbc
Copy link
Member

mtbc commented Feb 6, 2013

Heh, as there is diverse opinion, still good to merge. (-:

@manics manics closed this Feb 8, 2013
@joshmoore
Copy link
Member

@manics: ?

@manics
Copy link
Member Author

manics commented Feb 8, 2013

Hmm. I definitely didn't mean to close this.... unless deleting a branch closes it.

@manics manics reopened this Feb 8, 2013
@mtbc
Copy link
Member

mtbc commented Feb 8, 2013

It does. (Also, pushing extra commits to it makes them appear on the PR too, but you'd probably already noticed that.)

@joshmoore
Copy link
Member

Yup, knew both of those. Thanks for re-opening.

mtbc added a commit to mtbc/openmicroscopy that referenced this pull request Feb 11, 2013
Small tweaks, partly caused by comments on PRs ome#669, ome#690.
@manics
Copy link
Member Author

manics commented Feb 13, 2013

This will go into the rebased version of #729.

@manics manics closed this Feb 13, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants