@matthias I am trying to code this post, but the post and the first few comments below it can only be click+drag selected in a box form (I can’t highlight the text like usual). Any idea why? Thanks!
You mean, you can add codes to boxes that you can create by click+drag? In that case, you’re seeing the image coding interface. It should only appear when doing click+drag on images, such as the one at the top of the post. If you’re seeing it on normal text as well, we have a bug.
For me it appears only for the first image, so that bug probably is due to your browser. Try in latest Chrome if it works (it does for me), and if so tell me what browser it does not work in so that we can reproduce and fix this.
I’m in Safari, will try on Chrome and let you know. From Noemi’s first comment down, it works for me, but above that I see the image coding interface even on the text.
Thanks for the testing! Unfortunately there will be no real progress for a month until our Open Ethnographer is back from the mountains. But I’ll start to triage each issue and by putting it into our issue tracker where applicable. For some issues, we’ll also have to discuss together how to solve them best.
Here I am going through the issues:
True. Reported here now, we’ll deal with it.
Can you give us one or ideally several examples of real-world content: what to select and what got codes? I could not reproduce it right now when creating some random annotations. Anyway, reported here now.
Can’t reproduce it yet but reported it here. We’ll deal with it.
Confirmed, and already reported here.
Hmm we need to come up with a generic solution for that to make it worth implementing. Can I get feedback from the ethnographers on the following proposal:
We could make it configurable (under User Settings) which codes to include in the auto-completion suggestions. The options would look like this:
Include suggestions from:
(x) all topics
( ) topics with one of these Discourse tags: [___________________]
(x) all users
( ) the following users: [____________________]
(x) all languages
( ) my coding language
( ) my coding language and English
“Project” refers to whatever will be implemented after deciding this issue.
Reported here now – welcome to contribute directly there in the Github issue tracker if you like.
This happens when trying to add an annotation to the same portion of text for the third time (or more often). I reported this here now – also see there for a workaround until this gets fixed.
@supernova @Maja can you respond and let @matthias know if this solution for language will work?
@Jirka_Kocian @Richard @Jan please also take note of this post
1 Like
@amelia @matthias @Richard @Jirka_Kocian @supernova @Maja Hello All: Matthias: I hope we can solve the following problem. I am coding using hierarchies, as you can see on the attached example. What worries me that the parental code (Kościół/Church) informs us that there are no text fragments associated with it, while there are two, one per each “child.” It will be very important for our further work to be able to click on a parental code and see all the text fragments associated with it via its “children.”
. All my best. Ciao, J
Good point. I propose that after the changes, the parent tag from your example would look like this:
Kościół/Church (0 + 2)
So it would still show that it has “0” direct uses for annotations, but also indicate that its child codes are use “2” times in total. I have now included this into our development plan – open to changes if we find a better solution, of course.
I don’t understand this exactly. Right now, clicking on a code in the “Codes” section of the user interface will simply (un)fold the code hierarchy. Only when you click on “Annotations” in the horizontal menu following the code, as also seen in your screenshot, you will see the annotations for which this code is in use.
Do you propose that doing so should show the annotations not just of the parent code, but of the parent code and its sub-codes?
On another note, it seems that you use translations inside your code names. That is no longer needed for multi-lingual coding, as now codes can have multiple names, one per language. See this piece from the manual:
Hi @matthias, many thanks!
YES! Exactly.
@amelia @Jirka_Kocian @Maja @supernova Hey guys, in Kraków we decided to write codes in two languages, we can change this, but I still do not understand how to add the name of the code in another language. For example, per below, let’s assume I will write the code’s name only in Polish and then want to add its name in English. Where? I can change the language of the code’s name, but I do not see how I can add its name in another language. I may be dim…
About the requested list of annotations for parent code and its sub-codes: understood now. I added it to the development plan, and we may get back to you if this requires further discussion.
Just click the Add button seen in your screenshot, and a set of new form fields will appear. We are planning to improve this part of the user interface.
Aaaa, OK, I get it now. I thought that this button was designed to add another, new code, but you say that it will be a single code assigned to the same annotation, but in two languages, right? But it means that we will have two sets of codes, say one in Polish and one in English, assigned to the same set of annotations, no? Isn’t it easier of they are shown together, as I did, so someone who does not understand Polish can understand my code? Need to test it, but now need to run.
Yes, exactly. And for the way how the computer stores this information, this is the right solution: there is one code, and it has multiple names.
Right now, when looking at coded content in the “Coding View” of a Discourse topic, this system will show an annotation using, in this order:
- The code name in the user’s preferred language (see under “User Settings” for that). If not available:
- The code name in English. If not available:
- The code name in the original language it was coded in.
This behavior can be adapted and improved, but this is just a presentation issue. The computer knows that there is one code, and it has names in several languages which should be shown depending on context.
1 Like
Go it. Many thanks. Will start practicing right away. So, for now, the only outstanding issue is the first one that you have already noted and eventually we will have a solution. All best, J
1 Like
@matthias Sorry to bother you again (and I know it is late there - no ruch). So: (1) I changed the default language assigned to me to Polish, (2) created a new code “Kościół”, (3) turned into a parental code, (4) linked it to two children codes, (4) added its English name “Church” AND: it shows the English name on the list of codes, not Polish as I wanted.
I described above that the code name language in the coding view (when adding codes to a Discourse topic) should be Polish in this case, and I just confirmed it is by testing myself. So at least when coding, the system will suggest you the Polish names (not the English ones though, let me know in case you’d like to see the English ones in suggestions, too).
However, it makes complete sense to use the same way of determining code name display language in the list of codes, as you expect it to happen.
So yes, you found a bug. We’ll fix it for you. (The reason that there are so many issues with the list of codes is that it was originally only built as a tool to help us import old annotations, while the coding view was the main interface for ethnographers. Then it turned out to be more useful than expected for ethnographers, and so we’ll have to hone that part of the software a bit more. Some patience required 
)
Got it. Super! Many thanks. No rush - I know it is something under development. As you know, if get all those “tricks” right and the system and I will get synchronized, I can start rolling. Ciao.
Just so I understand properly – @matthias, is the new form of coding (where we do not label each code with both Polish/English codes but link them separately) going to produce an SSNA where both Polish and English codes are visible? for @alberto and I this is important (as well as the ethno team as a whole) since the SSNA needs to be readable by both English and non-English speakers of that language.
This can be done because the Open Ethnographer API supplies the code names in all available languages, see here in the manual, which also includes an example. It will need changes to the software used to create the SSNA. For Graphryder, this change is not yet done but I included it into the development plan here. For other software, such as Alberto’s scripts, that change would need to be made by whoever maintains it.
These options seem reasonable for us.
Isidora and Maja
1 Like
This is now implemented. When you go to the list of codes and click “Annotations” for any code there, you will see a list with a filter at the top saying “Include sub-codes: No”. There, you can now adjust to also include all children codes into this list, as requested.
Also fixed recently.
Also fixed recently, alongside with 27 other things.