Eana Eltu: Translator, Dictionary, API and putxìng.

[`Eylan Ayfalulukanä]

The other way to do what you propose with definitions and comments, is to put both in the left hand column. This would create a long open space to the right of each of these entries, long enough to accommodate most long definitions and comments. And you wouldn't have to create a third column.

In the future, when we are able to have some additional fields for citations, example sentences, etc., they could go underneath the definition and comment intems in the left column, as these items could be long as well.

[Tuiq]

The future is now. We can add fields to any template as we please - but better, I think, is that you could simply make a new template based on the old one (unless you want every word to have a citation, of course!)

The issue is that this is a table; it doesn't care if there's nothing on the right side. It will stay within its column, even if there would be plenty of space to the right.

[`Eylan Ayfalulukanä]

I think templates could be added in the same pattern as the Valyrian templates. I'll have to look at those tomorrow night and update you on them, unless you have them handy. Compared to Naʼvi, I am trying to keep the GoT templates simple.

But what I cannot figure out is why a field of zero length cannot simply be ignored during definition entry building. I know that there has to be a placeholder in the database for every possible record. But the databases I know of allow zero length records when the data is structured properly (I am not by any means a database expert!).

[Tuiq]

I was talking about the visual table. You know. <table><tbody><tr><td> and friends. The display-thingy, not the database-thingy. The database allows "empty" fields, of course. However, having an universal template that has every possible field and then just fill out those required for said word would be a bad design and probably make quite some trouble in the rendering later.

[Tuiq]

To illustrate what I mean (and what I thought you mean), I've temporarily colored the columns.



All content in the green column will stay in the green column, even if there would be space on the right. That's what I meant. Since comments and definitions tend to be longer, it would make sense to move them to a "third" column, like this:



However, you would need to tag fields as "This field is at the bottom and expands over both columns". Perhaps we could simply do a select box for this, with three lines? You'd have the option of "This line is displayed wide above all others", "This line is displayed columned with others" and "This line is displayed wide below all others". That would look like this:



In this case, "Definition" was tagged as wide-above-all, Comment as wide-below-all and the other fields are the default in-columns. All of these could be sortable within their block, too.

[`Eylan Ayfalulukanä]

Ma Tuiq, now I think I understand what you meant by the 'third column'. You are definitely on the right track, especially with the second-to-last example you gave. It puts the word first, and the long fields at the bottom where they can expand across columns.

As far as fields in the database, there is a definite limit to how many there would ever likely be. There is only so much detail that is practical to stick into a dictionary And the function of these fields is known. So, there is a very definite and practical limit on how much information might ever appear in a dictionary entry. A well thought-out database also gives you the ability to create different kinds of dictionaries, with different content, as you proposed in your discussion about the update. The Na'vi dictionary does this already, with the full, concise and part-of-speech versions.

[Tuiq]

To be completely fair, the difference between second-to-last and the last one isn't big. Instead of a checkbox it would be a select box - if you use it or not would be up to you. You could, of course, also set the definition as one of those first words.



This becomes a bit confusing with these few fields (Source looks a bit lost). Still, it would be a possibility that wouldn't add too much, programming/performance-wise. We could also introduce a new field type that would be used to define the word, i.e. where currently the template is displayed, said field would be displayed.



This also feels too displaced for me. It's kind of difficult to get it right, I think.

[`Eylan Ayfalulukanä]

Ma Tuiq, I am still not sure I understand what the check or select boxes are all about, as there are none in your examples (are there supposed to be)?

The first example in your last post is intriguing. I kind of like having the definition as the first entry after the Dotharki (or whatever language it is) word. The source field could go in the first column, like on one of your earlier examples. This would end it from being alone.

I like the second example in your last post a lot! It puts the Dothraki (or whatever language) word in a place by itself, where it visually 'anchors' the rest of the entry. Since you have saved a line by doing this, you could put the source in the same column as most of the other items. To save vertical space, you could put the template type below the Dothraki (or whatever language) word in a light font, so it wouldn't be noticed as much. In any case, it gives long fields plenty of room to the right without crowding.

[Tuiq]

No. The checkboxes/selection boxes that define how the field is displayed in the overview would, of course, be on the template edit page - not the overview. So you can't see it, but have to imagine that every field ("Dothraki", "IPA", ..., current-EE's "arguments", i.e. {}) would have an option attached to it that tells EE how to display it on the overview page. This edit page looks terrible right now, I'm currently working on a bootstrap-MVC-helper class thingy that allows me to quickly and easily create those things though.

If we move source to the first column, however, what good are the columns here? The issue is that we are wasting so much vertical space, not horizontal. We have plenty of horizontal space, removing the template type would give us even more of it.



That's for 10 words. On my normal-ish set up Firefox, each word takes up about 100px. In the end, I can't fit the whole list on my 1080p screen right now. As you can see, this is assuming that Source is still columned. If we remove the column completely and merged Dothraki in again...



The table is now a whooping 1140x1407px. You can also clearly see all the wasted space. About 20px per word per field that we do not column, which sounds about right. Note that I've taken Dothraki in the list again, too. Otherwise, it would be about 1200px tall - still too tall to be displayed properly.

If we keep using the non-columned system, but do not display Dothraki or empty fields (such as empty comments), we would end up with this:


Which is an improvement. However, keep in mind: Hiding fields can be dangerous. At least in programming, hiding often isn't a viable choice, as forgotten information is quite a bad thing to do. We would have, again, the option to do this on a per-field basis, i.e. say that "Of template Word, the field Comment may be omitted if empty". Another checkbox to Field, basically.

Let's do a bit more, though. Let's clean up the links for one thing. The problem becomes more apparent (I'll fix the buttons later so they'll nicely align to the right side of the table):



We're just wasting lots and lots and lots of space. I'm currently quite out of ideas to be honest.

A quick calculation though re: pages are not necessary: Assuming Na'vi has approximately 7 arguments per word (which is quite fair, considering there are a few floating around with 10..), 3800 * 7 * 20 would give you a page that is 532'000 px tall. Or, put differently, 18m of paper if you were to print it.

[Tìtstewan]

I have a question about this new thing, because I definely would support it. Will this replace the "old" stuff of EE?

[Tuiq]

Absolutely.

[Tìtstewan]

Awesome. Maybe I can play "test guy" since I have translated 30% of the romanian part only?

[Tuiq]

I'm afraid the project is a bit frozen right now and I'll likely re-start from scratch... I've made a "few" mistakes in the beginning that might end up really badly.

Also, the question of where this would be hosted remains unsolved. I'm not sure to which extend Mono supports ASP.NET, nor how well maintained the MySQL adapters are.

[Tìtstewan]

At the moment, time should be not our problem. But I would really support a new look of that EE.

[`Eylan Ayfalulukanä]

I haven't gone anywhere, either. I have just been very busy, especially with work.

[Tuiq]

The main issue is that I have a bit too many things on my plate right now. Looking for a programming job without any sort of degree is kind of difficult (unless you're a big fan of PHP/Java...) so I'm trying a lot of things at once.

EE.NET could certainly be useful as something to show off, but I'm not entirely certain how well it will play out on Mono and therefore be used at all (Windows servers are expensive). I'm currently installing everything required in a Debian VM and if those tests go well I might be able to host (and therefore develop) EE on a friend's server.

I would likely do a lot of things different these days; certainly parts of the code can be copied but there's so much I did wrong. Not surprisingly, however, as it was my first "real" project with ASP.NET and bootstrap.

[Ftiafpi]

I would likely do a lot of things different these days; certainly parts of the code can be copied but there's so much I did wrong. Not surprisingly, however, as it was my first "real" project with ASP.NET and bootstrap.

Hey, for a first project it worked great.

[Tuiq]

I would likely do a lot of things different these days; certainly parts of the code can be copied but there's so much I did wrong. Not surprisingly, however, as it was my first "real" project with ASP.NET and bootstrap.

Hey, for a first project it worked great.

Oh, that wasn't ASP.NET. That was Perl. Or rather, a mwForum "extension" - something that I was already somewhat fluent in. It's the new EE that I'm talking about.

(However, EE's current code is quite awful)

[Ftiafpi]

I would likely do a lot of things different these days; certainly parts of the code can be copied but there's so much I did wrong. Not surprisingly, however, as it was my first "real" project with ASP.NET and bootstrap.

Hey, for a first project it worked great.

Oh, that wasn't ASP.NET. That was Perl. Or rather, a mwForum "extension" - something that I was already somewhat fluent in. It's the new EE that I'm talking about.

(However, EE's current code is quite awful)

Oh, I missed that. Whoops.

[Tuiq]

Well, I guess that's it. After "playing" (read: torturing myself) with Mono for two whole days, I've had enough. The project's dead. ASP.NET would be nice and all, but it's not doable on other platforms. I don't know anyone with a Windows server either, so the project is dead until I find something else that I like.

It's definitely not going to be a remake in Perl.