Sebastian Goll

Welcome!

Hello, welcome to Wiktionary, and thank you for your contribution so far. Here are a few good links for newcomers:

• How to edit a page is a concise list of technical guidelines to the wiki format we use here: how to, for example, make text boldfaced or create hyperlinks. Feel free to practice in the sandbox. If you would like a slower introduction we have a short tutorial.
• Entry layout explained (ELE) is a detailed policy documenting how Wiktionary pages should be formatted. All entries should conform to this standard, the easiest way to do this is to copy exactly an existing page for a similar word.
• Our Criteria for inclusion (CFI) define exactly which words Wiktionary is interested in including. There is also a list of things that Wiktionary is not for a higher level overview.
• The FAQ aims to answer most of your remaining questions, and there are several help pages that you can browse for more information.
• We have discussion rooms in which you can ask any question about Wiktionary or its entries, a glossary of our technical jargon, and some hints for dealing with the more common communication issues.

I hope you enjoy editing here and being a Wiktionarian! If you have any questions, bring them to the Wiktionary:Information desk, or ask me on my talk page. If you do so, please sign your posts with four tildes: ~~~~ which automatically produces your username and the current date and time.

Again, welcome! Razorflame 16:53, 7 January 2010 (UTC)

Na'vi diphthongs

Assuming a syllabification of CV.CV.CV, and not CVC.VC.V, I assume that aya is /a.ja/. There's no distinction, it would appear, between ay-a /ai̯.a/ and a-ya /a.ja/ in Na'vi. (Actually, since syllabification is not phonemic, we technically shouldn't have it between slashes, but it's useful for our readers, since e.g. /a.fŋa/ would be unintuitive.) kwami 21:30, 8 January 2010 (UTC)

Templates

Please use talk page for documentation and put {{seeTalk}} on the main page. Conrad.Irwin 16:36, 23 January 2010 (UTC)

Thanks for making me aware of it. Is this correct?

Should I also use separate documentation pages for the internal helper templates NaviHW/ipa, NaviHW/noun, and NaviHW/verb? Sebastian…talk 17:05, 23 January 2010 (UTC)

There is some practice of redirecting their talk pages to the main template's talk page, but that is not usually necessary, up to you. Thanks for moving the /doc's so promptly. Conrad.Irwin 17:10, 23 January 2010 (UTC)

Na'vi /a/

Hey,

We still don't know which vowel Na'vi /a/ is. Frommer said it's a central vowel like American English hot. However, American hot is a back vowel. The diff from RP is that it's not rounded. Also, Frommer worked on Persian, which also has a rounded back vowel like RP. I've asked him to clarify. He apparently misspoke, but I don't know in which way he misspoke. kwami 04:57, 26 January 2010 (UTC)

Okay, let's wait and see what he tells us – converting to whatever we end up with shouldn't be that difficult. I guess I could have noticed the contradiction in his post if I were a native speaker. Thanks for pointing it out! I only saw his IPA "[a]" and "low central vowel", and with [a] being used for the vowel in Spanish and Italian, both of which he compared the Na'vi vowel to in his post. Sebastian…talk 05:24, 26 January 2010 (UTC)

Ah, it's his New York accent. He pronounces hot w an [a]. kwami 20:25, 21 February 2010 (UTC)

streamlining the templates

Hey Sebastian,

I've tried migrating the appendix over to Wikibooks, so that it (or part of it) could be added to the Na'vi book there. But there's a limit on how many templates can appear on a page, and evidently this limit includes any templates called from the page, not just coded directly, so the words only display through the beginning of T. (And that's before we expand the dict.) Solutions would be to break up the dict, or to streamline the templates. Can you think of any way to do the latter?

I asked at Wikibooks, and s.o. said, "They appear a bit overengineered to me: you are using only a fraction of the possibilities, right? One way of simplifying the templates might be to define a whole set of expanded versions of these templates (by using "subst"). And then defining expanded versions of the templates that you are using with the specific parameter values that you are using most often. I assume that this will reduce the size significantly."

I'm not familiar with "subst", but I take it this would mean a larger number of more specific templates, rather than using parameters to call subtemplates. kwami 19:57, 8 March 2010 (UTC)

That's right. "subst" substitutes the template right where it is called, when you edit a page; i.e., using e.g. {{subst:smallcaps|text}} ends up not as the template call as you wrote it but as whatever that template evaluated to at the time the page was edited; in this case: <span style="font-variant:small-caps;">text</span>.

So, instead of using the nested template structure with sub-templates that we have now, we could use a bunch of specialized templates, e.g. {{NaviHW/n|...}}, {{NaviHW/v|...}}, etc., instead of {{NaviHW|n|...}} and {{NaviHW|v|...}}. The problem with that would be to keep them all in sync when we change how the general structure of dictionary entries should look like.

But still it might be worth the effort: you've probably already noticed that making changes to the dictionary takes several seconds before the new page is rendered: that's the time the MediaWiki software needs to evaluate all the templates. To avoid this delay (and the load on the servers that comes with it) Wikibooks apparently decided to limit template evaluation within each page. BTW, do you know (roughly) what that limit is?

I think I'll try to streamline the templates somewhat and make them less nested. The structure for dictionary entries should be more or less fixed by now after all: headword followed by scientific notation followed by IPA transcription, followed by anything else that might depend on the specific POS. I don't expect to see a lot of changes to that in the future, so the duplication of code we'd have with specialized templates might not be as bad as it would be otherwise.

But eventually we might have to split the dictionary anyway: with 1000 additional words coming up, we could still hit the limit on Wikibooks. Thus, yet another approach would be to always use "subst" when calling {{NaviHW}}: that way, we'd lose the ability to change the look of everything at once by changing the templates but we'd greatly reduce the load on the servers since there wouldn't be any templates at all in the final document. Maybe (I'll have to think some more about that) we could still (automatically) include the original template call within HTML comments <!-- ... -->, so as to make it easier to (automatically; by a bot maybe?) re-substitute all templates when we need to ... Sebastian…talk 21:13, 8 March 2010 (UTC)

BTW, do you want to move the entire dictionary over to Wikibooks, or just copy parts of it? Sebastian…talk 21:22, 8 March 2010 (UTC)

I copied the whole thing to test it (it's at Na'vi/Na'vi-English dictionary‎), but was going to cut out anything we can't confirm w Frommer before making it public. I'd rather be missing a few correct words than include spurious ones. Was also planning on an English-Na'vi dict; if we have all the Na'vi entries together, we could link to them, but if they're split up it probably wouldn't be worth the bother. kwami 01:10, 9 March 2010 (UTC)

Regarding my final thought above: it turns out that it is indeed possible to have templates evaluate to something that (a) appears within an HTML comment, and (b) is the actual template call used to produce the concrete result – a self-reproducing template! :)

You can check out my first doodle with {{NaviHW/dev|foo|bar}}. If you write {{subst:NaviHW/dev|foo|bar}} in the sandbox, you'll end up with Test-foo-bar<!-- {{subst:NaviHW/dev|foo|bar}} -->, i.e., the "real" text that the template is to produce ("Test-foo-bar"; in the dictionary that would be the headword with all the necessary formatting), with the Wikitext necessary to reproduce the template if one wanted only to change a single parameter, or say: change the POS which might lead to a different headword formatting (verb infixes instead of plural forms et al., which might be hard or annoying to do manually).

The greatest advantage here is that the actual Wikitext that gets stored doesn't contain any templates anymore: no additional load on the server when only a couple words are changed (right now, the entire dictionary is re-evaluated whenever anything gets changed), and no limit on the number of words we can put on a single page. Sebastian…talk 00:36, 10 March 2010 (UTC)

So, if we changed the template, then to change the dict., we would need to copy over the template from the comments and then resave? For every entry? (Sorry I didn't answer for so long. I haven't been on wiktionary for a while.) kwami 14:00, 20 March 2010 (UTC)

Yeah, exactly. That's the price we had to pay for not using thousands of template includes. But I was thinking that we probably wouldn't change the template in any fundamental way in the future, and if we did we could easily update all includes at once using an automated script (I might even write a bot that does that periodically). The main idea here is that we want to reduce the load on the Wiki servers by substituting the templates instead of including them while still being able to update any single entry (hence including the original template call in comments). Sebastian…talk 14:37, 20 March 2010 (UTC)

Another thing to think about: would it be difficult to allow manual formatting of the header? Say if we wanted to underline teh stressed syllable? kwami 14:00, 20 March 2010 (UTC)

Manual formatting in general or only in specific instances? For the latter, I could simply add another named argument to overwrite the header. If we wanted to do that in general it might be worthwhile to think some more about it: right now, we create both the header and the plain-text anchor from the entry's positional template arguments; for different POS we do this in a different way, e.g., verbs have up to 3 positional arguments that together form the header and anchor. Using formatting here would work for the header but would also screw up the anchor; that said, we'd always have to include at least the plain text header (used for the anchor) and the header with any additional decoration (used for what is visible). Sebastian…talk 14:37, 20 March 2010 (UTC)

It might be worthwhile to do the underlining; people are used to it, and it's more immediate than referring to the IPA. And we don't need the anchor for all words, unless we link from the English-Navi dict. That would be nice, but starts running into template constraints again, unless we link by hand. (And if we underline on the Eng-Nav side,--and really who wants to have to look up each word a second time just to get the stress,--we'd have the same problem with having to double enter everything on that side too.) kwami 18:58, 20 March 2010 (UTC)