This page is intended as a first point of call for questions relating to the representation and resolution of issues relating to Wiktionary language and internationalisation considerations.
Am I right in assuming that one reason for having language namespaces is to create a translation (i.e. French-English English-French, etcetera) dictionary? If so, we need something more flexible than the language links on Wikipedia. As it is sometimes they totter at the edge of uselessness due simply to varying meanings of words. For an example, my little pocket English-Spanish gives 44 different translations for set, to say nothing of "set about", "set to", etc. There is no single word you could link set to on es:Wikcionario that could possibly be of any value. You would need to be able to put ], ], etc, as links within the text, as a bare minimum.
Also, a major part of a translating dictionary is idioms; I'm just worried that any attempt to feasibly set up a translation dictionary will just spin out of control. - Montrealais
My original idea for tranlations was this:
links foreign language pages.
en.wiktionary.orghttps://dictious.com/en/Dog - is my definition page
then languages could be directed to:
en.wiktionary.orghttps://dictious.com/en/Dog-language code eg
en.wiktionary.orghttps://dictious.com/en/Dog-es on that page it could explain if its a 100% definition or a near translation.
- fonzy
OK, I think if we just use English explanations of foreign terms, it's reasonable and desirable to have it all on the same site, i.e. this one. If we had a German explanation of an English or French term, we would want to have it on a separate, German site. So I think we should move quickly to get
set up, possibly others. Then if you wanted to link to the German explanation of a word, you would use ] etc.
I think it would be desirable to have one language per page only and create disambiguation pages (I hate this manual mechanism, we need something better in the long term) otherwise. It would also be useful to have some kind of flag (not a namespace that would require changing link patterns) to specify which language a specific word is in. That way, we can then create filters to show only changes to pages in language X / only export articles in langauge X etc. If we just use (foo) in the articles to specify the language, this filtering gets harder, and it becomes possible to mix and easier to make mistakes. --Eloquence
Brion this url is only temporary it is hoped to be moved to language code.wiktionary.org soon. - fonzy
For the moment I think we should just concentrate on the main English Wiktionary not bother about translations yet, yes it can sill be discussed but i thik proposed templates need to be in order otherwse we maybe in a mess with lots of diffrent style defintion pages. - fonzy
By starting this project from the ground up, there are a lot of interesting possibilities. Hopefully people will choose a way that gives the Wiktionary to be as great as it can be. I do have a few observations at this point, and so early on they can't be much more than that.
"See en:Wikipedia:Complete_list_of_language_wikis_available or ISO 639 Language Codes to see what languages the abbreviations stand for." A message like this and/or an excerpt of the list should be in a more prominent place. Patrick 11:35 Dec 13, 2002 (UTC)
You can use the name wikipedia more or less international. Mayby people will ask to say it again if you talk about it, but it is not a to difficult word. Wiktionary is a difficult word. Mayby not for English, but not very good for international use I think. If people do not understand the name the will not find the website. 62.102.4.189 12:27 Dec 13, 2002 (UTC)
Can you think of a better name for wiktionary then?? - fonzy
On including non-english words, are we only including non-english words which are used in the english language or all non-english word ? --Imran 21:19 Dec 16, 2002 (UTC)
Any known word in the whoel word (any language) can be added, its jut the definiton useage, informatioan about it thats in English. - fonzy
Say i was looking around and saw a Japanese Word in Japanese letters, tehn i could cut and paste put it in Wiktionary and **poof** i can see what it means. -fonzy
Also I think it would defy the point of wiktioanry, someone who is learning chinese may find it helpful having translations and describing the useage etc.
Any oen thought of creating verb tables? French Verb Table, Spanish Verb Table, etc
Is there a move planned to fr.wiktionary.org for the French version ? I have a lot of work for my school, but I'd like to help a bit once a week (Saturday). Thanks Brion for the move to wiktionary.org :-)-- Youssefsan
I have no real objections, but i would prefer wiktionary to have the same format as wikipedia, as i like things to be constant. - fonzy
IMO language links should work the same here as they do in wikipedia. In Wiktionary the subjects of articles are words. These words can be any word in any language. Therefore all language Wiktionarys will eventually have an article on the English word dog. This will be spelt the same way and look the same in all language Wiktionarys since the subject is the English word dog. Therefore interlanguage links should be of the magical variety but they will have very predictable forms on the dog page such as ], ], ], ] (unless there are ambiguity issues with words in other languages that are also spelt "dog"). Links outside of Wiktionary need to be a bit more complicated and also be inline with the text. For example the link to the article named dog on the English Wikipedia should be something like ] (and the reverse should be ]). We needn't make interlanguage linking here more difficult just because Wikipedia also has interlanguage linking. --Maveric149
Although the differences between AME and BRE spelling are being discussed, the differences between AME and BRE pronunciation for the same word have only been mentioned, and differences between the AME and BRE meaning of the same word have not been discussed. For example, in pronunciation, BRE vowels are not pronounced the same as AME vowels in the same word - cf. BRE "lot" and AME "lot." And, an example in meaning, BRE "lift" means "elevator," but AME "lift" does not. RoseParks
This article raises some interesting questions about how we define our borders between the Wiktionaries in different languages.
"Lente" is not used in contemporary English. (I believe it was used in older forms of English, but I don't think it would be helpful to go there at this time.)
We do need to maintain some perspective on the fact that this is the English Wiktionary. If, for example, we start including what the Spanish translation is for a Dutch word the articles could quickly get out of hand when you contemplate the number of possible language pair. If you admit L languages, then the number of language pairs will be L*(L-1)/2; a mere 10 languages implies 45 possible language pairs, 90 if you consider that translation go in two directions.
I would propose then that the translation section be limited to foreign translations of English words. We already have the English translation of foreign words in an earlier part of the article. The Spanish/Dutch pairs would properly appear on the Spanish and Dutch Wiktionaries. Eclecticology 21:15 Dec 19, 2002 (UTC)
Shouldn't this be a disambiguation page? The subjects of Wiktionary articles are all words in all languages so just because words in different languages share the same spelling doesn't mean that they are the same. They are different words and therefore need their own pages. IMO the syntax should be Lente (es) with Lente having a list of all the words. --Maveric149
I think there should be separate namespaces for each translating dictionary, or maybe sub-namespaces. So en:dog would be an entry in English about the English usage, and es-en:perro (or maybe es:en:perro or en:es:perro) would be an entry in English about the Spanish usage. For an article in the en: namespace, en:dog would of course be equivalent to dog. -- Merphant
About the language considerations, I've got an idea, but I'm sure this is NOT hard to code, but that would take the source far away from the wikipedia's one, and I hope that you're trying to keep one source for both applications.
The idea is this one : having (in the database) the pages for the same word used in several language (ex: Chat in english and Chat in french) stored in different entries. I will use for example the Brion's notation, that I like too, but actual wikipedia's notation is also fine...
http://wiktionary.org/en/Chat will contains both definitions, the one for the English "chat", and the one for the French "chat".
http://wiktionary.org/en/fr/Chat will only give the definition of the french word in english. While http://wiktionary.org/fr/en/Chat will give you the definition of the english word in french.
If you consider that there is only one database for all languages, you can also imagine browsing http://wiktionary.orghttps://dictious.com/en/fr/Chat to get all the definitions of the french word in all languages. http://wiktionary.orghttps://dictious.com/en/Chat will let you read all the definitions of all the words in all languages. Of course, if "wiki" can't be used (for compatibility reasons with the current wiktionary, you can use "all" or "_" or anything, details aren't important, I prefer the idea than the details).
The main advantage to have differents pages (at least in the database, even if you browse all of them at once) for the same word in differents language, is that you'll be able to extract ONE dictionary of all english words in english, and then one dictionary of all french words in english, etc.
If you start mixing up the different pages in wiktionary.org/en/Chat, you won't be able to do that. -- AGiss from french Wikipedia
I am not sure to understand why one would want the definition of an english word in spanish or french (or definition of a french or spanish word in english). Either the definition in english is enough, or the translation in french or spanish is enough. A french/french (or spanish/spanish) dictionary contains the definition of the word in french (or spanish), if the end-user wants to have a definition in his/her language.
Also, why not considering pure translation dictionaries namespaces. For instance, Spanish/English, and English/Spanish. I am sure this has been proposed already, but I would like to know why there is not a clear distinction between definition dictionaries and translation dictionaries.
Moreover, a translation dictionary is more than a one-to-one relationship between words. For each entry, we have usually several translations, and the example of 'en:cat' translated into 'fr:chat' and 'es:gato' simplifies the problem too much. How would you translate 'en:set'?
By having separate functionality dictionaries (definition and translation), we can link, if we want, the definition of 'en:cat' (in the English Definition Dictionary) to its translation into french '->fr' (English/French Translation Dictionary) or spanish '->es' (English/Spanish Translation Dictionary). This sounds more dynamic to me than the current state of this page, where Wikipedians may duplicate information.
I am new to Wikipedian, and did not find dictionary related threads in Intlwiki-l mailing lists archives. Sorry if these ideas have been already proposed and discussed, and if so, please orient me to the appropriate archives. Nicolas Delahaye 09:03 Feb 5, 2003 (UTC)
THe structure you have done is abit too complicated and untidy. -fonzy
I too have been thinking about the structure of Wiktionary and of the problems concerning definitions-translations.
I have had a look at Nicolas' test pages and I find them very interesting. Yes, they are a little bit more complicated than what we're doing now, but I don't agree with Fonzy's remark that they are untidy (I wonder why because no explanations are given). I think the structure is quite orderly and I feel comfortable using it. It might even be taken a step further: a connection between the different language Wiktionaries. I'll try to explain it with an example.
On User:Nicolas Delahaye/test/en/en/gear the definitions of gear are given. The page has links to the translating pages for that word, e.g. User:Nicolas Delahaye/test/en/fr/gear (English -> French). When a translation is clicked (e.g. appareil) the page which gives the translations of that word in English is shown. Apart from the links to the two previous pages it could also have a link to the page where the French definitions of appareil are given, i.e. to the French language Wiktionary.
These are my views for the time being (no doubt I will have to adapt them :-) D.D. 21:29 Mar 3, 2003 (UTC)
By untidy i don't mean untidy looking, i mean untidy in an organization sence, do you understand :-s ? Also knowing newbies they wont link everything up properly, just making more work. -fonzy
O this is jsut apoint incase you don't know Brions idea of one database for wikipedia and wiktionary would mean that the urls woudl look like: http://wikipedia.org/{language code}/i dont know if wiki will be put here/article. -fonzy
Although I have no strong interests in Nicholas's proposal, and a lot of uncertainty about where it's going, I'm more than willing to give it a chance to succeed. There's already enough to do in our respective areas of interest to keep an army busy for a long time.
With the prolifertation of these indexes though, we should find some consistent way of naming them, or many of them will just get lost. Something that begins with or or anything else of the sort would be fine with me. The one thing that I oppose here is having them titled as if they were just another article about a word. Eclecticology 08:37 Mar 5, 2003 (UTC)
I do not support the proposal either but will will allow Nicolas to create about 12 entries using his format just to see how it goes. - fonzy
Having links to all possible translations in all possible languages creates a mess. User should have the possibility to define what s/he is looking for, and get only this. If I am looking for a Polish translation of an English word, I am not interested in Quechua or French translations.
Another thing is free-formedness of the entries. It is OK with encyclopaedia, but not with a dictionary. People will enter here a lot of very useful data: grammatical information, conjugation tables, usage examples, possible translations, comments on usage etc. If you will not provide a way to programmaticaly parse this data for later export, it is going to be a lost work and lost opportunity, that this project has. A dictionary is a database. How do you think, what is better - a list of free form unparseable notes on words or well structured database that can be easily exported to any other format or database?
I would personally use XML as a way to structure the entries and export this dictionary. Yesterday I edited this article and described how I would personally try to do this. I deleted this, because it would need rewriting Wiki for the dictionary, and after I saw where you already are I feel this idea will not be accepted.
David.
I do not know what is RE - I learned about Wiki yesterday. I will have to learn :-)
Although Wiktionary using free-format, it is not that mess.
Well, it is. The entry is in free format. It can not be processed by a program. It can not be exported in an importable form. The data can not be used elswhere - it means almost all the work your users put into creating the dictionary is lost. You can only browse that dictionary on the net, nothing more.
Most of the articles created are obeying some common rules.
So they look similar. Only that. You can not, for example, write a program that will create a list of irregular verbs from the dictionary data, can you?
We don't use strict format because Wiktionary should be easy to edit, otherwise many new comers will find it uninteresting to contribute.
I believe much more people are familiar with XML rules (they are extremely easy) than with Wiki formatting. If they do not know the rules, they will be more interested to learn a little of XML than your common rules. Please, believe me, using XML will not make it much more difficult. You can use forms to accept the data. It can be made much easier than it is now. And let me tell that, I do love the idea of this project. I would like to contribute entries here, write scripts to easy check words from this dictionary etc. But I prefer to use my own local database, because in my opinion submitting to such free-form is a work in vain. You can not reuse this data in any way. It is better to have less of quality data than have a lot of mess. If people will see that you do a good work, they will learn what they need to contribute. Especially, that in fact you can provide forms (or even special, dedicated programs) so they do not have to learn anything.
Other reason is that because we have not grasp enough all the possibilities of all the languages yet.
This Wiki is written in PHP, isn't it? Working with XML in PHP is easy. You need one evening to learn everything you need to make it work here: you need to know how to check input against a DTD and how to generate HTML from XML. I think parsing XML would be a lot easier than parsing Wiki markup.
We are in trial-and-error step now. Adding new articles or editing existing articles is a required step to find these possibilities.
The problem is that once you have some significant amount of unparseable data introducing a good change would require throwing all this data away and starting from the scratch. Well structured, parseable data can be converted to new format. Your current format can't. In my opinion you are going in wrong direction. :-(
David
I do not know what is RE
Did you mean regular expressions? If you did mean regular expressions and not some magic trick, my answer is: no, you can not do it using regular expressions.
XML would be MUCH, MUCH, MUCH, MUCH better: easier to parse, forbidding to let ill-formed input, never making mistakes during the parsing, easy to transform. You can not have all this with regular expressions.
David
Hi David,
Hi Poliglot,
thank you for considering what I said.
I am convinced that if Wiktionary doesn't adopt it, an other project will do it
I found your project just because I was looking for some Wiki to start my own project exactly like yours. But because you already started it, I will not do it.
I believe XML would be best for the markup of entries. You could allow some subset of xhtml in places where it would be appropriate.
Did you have a look at Reta vortaro?
No, I hear the name for the first time. I will try to find this project and have a look :-)
I would like to chat with you a bit about xml and its possibilities. I'm trying to have it being rendered in Mozilla using xsl. Would you mind I ask you a few questions?
It will be my pleasure. I will send you an e-mail.
But to make it clear, in my vision even though the Wiktionary would use a combination of XML and database tables to store its data, it would not send raw XML to the browser and force it to displaz it. The data MUST be converted to xhtml and just sent to client. Only if the XML data is requested (probabely because it is not a web browser that is requesting it) raw XML conforming to published DTD should be sent.
Since two years I have also been designing a database schema to store words
I think such a schema should separate some part that is common to all the languages and should let custom definitions below some level - just becase languages differ. I certainly would like to have a look on your work, thank you for your proposition.
As to my vision of all-the-languages-in-the-world dictionary... I created some solution for my own needs - a local database that allows to enter a dictionary for any language. It uses a combination that I proposed for Wiktionary. I use it to check words in Internet Explorer when I browse the net. It works like this: I highlight the word I wont to check and right click it. I choose translate from the context menu and it displays me what I have in my database (I only have a chinese database) - the data that I imported is not editable, my own tables are editable. If there is no entry, I just click Add to enter it to the dataabase. I think the easiest way to illustrate my point would be to let you have a look on it... I can mail it to you, if your mailbox will acceept an e-mail with big attachment (have to check how big - maybe about 3 MB). The disadvantage is that I only work on Windows - I did not care to make this solution to work on Mozilla or Linux. Database is MS Access file, scripts will work in IE only... So... are you interested?
I will try to post a few screenshots here, I only have to check how to do it... one moment, please...
David
I post this screenshots here, because this solution can be easily made to work with Wictionary
And makes adding new entries quick and easy, doesn't it? :-)
We are reading a Chinese web page. We see a word we do not know. We highlight it:
Highlighting a word to look up
We see what is currently in the dictionary:
We want to add new translation. We click Add...:
And we see the results:
Displaying new dictionary entry
I repeat: this can work with Wiktionary. This can work with any language. This can work from within Internet Explorer and MS Word. A better programmer can make similar solution to work with anything that is on the screen...
David
PS: Poliglot, should I send this to you to let you have a look on the database, scripts etc.?
Other reason is that because we have not grasp enough all the possibilities of all the languages yet.
I guess I misunderstood you when reading it for the first time. I believe that the best way is to have the structure that is common to all the languages expressed in database structure. Everything that changes and should be flexible, can be encoded in XML. Access to this data will be slower, but will be possible from a program or script.
You will NEVER forsee all the needs people might have to encode dictionary data in the languages you never heard of, becase some are specific for each language (and some are common to all of them). Because you will never know anybody's needs, you have to leave yourself enough flexibility to adapt and not to have to change or discard anything you already have. This can be done with XML easier than with other solutions.
Should I try to explain how I would do it, if I were starting this project from a scratch? I mean I admire what you try to do, and I do not want to offend anybody, I just see the big weakness of your approach: an entry here is a free-form note, not a database record.
David.
Did you have a look at Reta vortaro?
Well, just one look a second ago. This is how it should be done. I did not analyze their DTD... but it seems there is nothing one might dislike there.
I would certainly prefer to submit my Esperanto etries there, not here. If I were a professor, I would prefer my students to help their project, not Esperanto Wiktionary as it looks to be at the moment.
Why? Because they generate good, clean, usable data. Their format has more potential. It would be a matter of minutes to convert their dictionary to clean, top-quality Wiktionary entries. On the other hand, converting Wiktionary entries to their format would need manual work - slow, troublesome, expensive, prone to errors.
David
( Haqqax + at + yahoo + dot + com )
<?xml version="1.0" encoding="utf-8" ?> <?xml-stylesheet type="text/xsl" href="vortaro.xsl" ?>
<Entry> <Language name="English">
<PartOfSpeech name="Noun"> <Syllables>bath-room</Syllables> <Plural>bathrooms</Plural>
<Definition>Room where one can <link>bathe</link>.</Definition> <Translations> <Translation language="Dutch" gender="m">badkamer</Translation> <Translation language="Esperanto">banĉambro</Translation> <Translation language="French" gender="f">salle de bains</Translation> <Translation language="German" gender="">Badezimmer</Translation> <Translation language="Spanish" gender="m">cuarto de baño</Translation> <Translation language="Turkish" gender="n">banyo</Translation> </Translations>
<Definition>Room where the <link>toilet</link> is.</Definition> <Translations> <Translation language="Dutch" gender="n">toilet</Translation> <Translation language="Esperanto">necesejo</Translation> <Translation language="French" gender="f">toilette</Translation> <Translation language="German" gender="n">Klosett</Translation> <Translation language="German" gender="n">Klo</Translation> <Translation language="Spanish" gender="m">cuarto de baño</Translation> <Translation language="Spanish" gender="m">baño</Translation> <Translation language="Turkish" gender="n" irregularAccusative="tuvaleti">tuvalet</Translation> </Translations> </PartOfSpeech> </Language> </Entry>
it would be possible to parse it with a program, but it would not be as easy as with xml.
In my opinion it would merely be possible to try to parse the entry - and the difference in meaning is important.
I don't know how to write a DTD or an XML schema for it.
You know how to plan good structure for the data. It is enough for the moment, because you are doing real work just now. Once the structure is defined, expressing it in DTD or schema is easy. You will learn how to do it when you need it or someone will help you.
I would prefer to use XML schema though, since it is XML and can be parsed just as easily.
Schema would be better, it is more powerfull. But I am not sure whether it is possible to use schema to validate XML in PHP... And I would have to check how easy/difficult would it be to achieve some useful modularity, that I know how to achieve in DTD, but do not how to do it in schema... I personally did not use schema so far.
But I agree with you - if we can do it with schema, it would be better to use schema, not DTD.
This is what I came up with:
<?xml version="1.0" encoding="utf-8" ?> <?xml-stylesheet type="text/xsl" href="vortaro.xsl" ?> <Entry> ... </Entry>
You want to have more than one "Entry", don't you? If you do, it can not be a root element, because there can be only one root element. It should be something like:
<?xml version="1.0" encoding="utf-8" ?>
<?xml-stylesheet type="text/xsl" href="vortaro.xsl" ?>
<Dictionary>
<Entry>
...
</Entry>
<Entry>
...
</Entry>
<Entry>
...
</Entry>
</Dictionary>
I would like to propose some modifications to your structure, but right now I do not have time for this. I will try to write more a little later.
If this is what you would let people edit, then nothing needs to be changed to the software of Wiktionary.
I do not think it is a good idea to throw too much at the user at the same time. I would prefer to let them edit only a part of the entry at a time. For example they click to edit Turkish traslation they are editing only this:
<Translation language="Turkish" gender="n">banyo</Translation>
And we can and probabely should provide a form for this. They can choose gender from drop-down list and write translation.
We cannot really change a lot about it.
This project has quite different needs than Wikipedia. The software should be modified.
If you feel up to the challenge
I believe this project has the potential to become much more important than Wikipedia itself. People just use dictionaries more often than encyclopaedia. Because of this it is a great honour to make it better in any way. I would definitely love to do whatever I can to make it suceed.
But you are talking here about big responsibility. Any mistake made during defining the database can have a great impact on the whole project. I never wrote programs for Internet. I do not use PHP. I believe I can write the scripts to do what I am talking about, but I lack experience. The other problem is, that I do not know when to do it. I have problems to find time to get enough sleep. I am not the best person for the task.
But I will try to read the source of this Wiki. I will try to find some computer to install Linux, Apache, MySQL and PHP to run a few tests. Maybe then I will have something interesting to say :-)
The problem with something like the above xml, is that it doesn't look very friendly to edit.
It can be made friendly. We will provide forms with drop-down lists, edit boxes etc. If we want to allow free form entries ( <comment> </comment> for example) we can allow carefully choosen subset of xhtml (paragraphs, tables, basic formatting etc.) with some extesions (for example marking up proper names to enable generation of indexes). Many people know HTML, so learning this markup would be easy for them.
The reason I have never contributed there in the 2,5 years I know about it, is that the threshold is a lot higher. One cannot just add or edit entries on a whim.
Wiktionary can be made to create the same quality data. Easiness of editing just means it is much easier to enter 'noise' - this project will need a community of proofreaders, scholars, users dedicated to protect the quality of the database.
In the evening I will write a little more about the XML you propose, Polyglot. We can take it as the beginning of the definition of Wiktionary data format.
David.
Currently a lot of duplicate input is needed. When i want to add a new translation from english to french I have to add new pages for both words, then add the words to indexes and so on..
There should be a database which contains links bitween different wiktionary and wikipedia entries (also in different languages). These links have to be "symmetrical" so that when I say A is a translation of B, then it is shown on both pages.(Users who dont want to see them can turn them off)
When I add link that says that A is a synonym of B then it is shown on both pages, when I add a link that A is the opposite of B then it should be shown on both pages and so on.
Please add more heads in this page. This way it becomes easier to respond to a topic (since you can have links for each section). Guaka 23:48, 29 Aug 2003 (UTC)
Remember, XML is a data markup language not a screen formating language, so highlighting words and specific list types (number vs. bullet) are not part of XML. So PHP may still need to be part of the equation. XML would be better for portability to other media such as hand helds, print and braile. XML also lends itself better to a more sturtured entry of information as a base but still allows for creativity and flexablity in data storage. Good parcers exist for XML today.
I'm assuming that Greek translations are intended to be modern Greek and spelled in Greek letters. Many of the translations I see are either ancient Greek, transliterated into the Roman alphabet, or both. Here are my suggestions for setting up a standard:
"* Greek: modern_translation (modern); ancient_translations (ancient)" or something similar
What do people think? Paul G 10:11, 17 Dec 2003 (UTC)
The probable reason why this happens is because most people can't type Greek characters. Feel free to transliterate. I would make a difference between Modern Greek and Ancient Greek. They are like two different languages anyway. My problem is that I know a little bit of Modern Greek, but not enough to tell whether something is Modern or Ancient Greek. Polyglot 10:26, 17 Dec 2003 (UTC)
I have two things:
IMHO both should be configurable by the user. Default can be EN EN. When a word is known for a language and there is an English synonym, you can present the English explanation if there is none in that language. When an English explanation is presented when an other language is requested, a standard text can be presented to request the user to do the WIKI thing.. When a new word is added from within a translation, it is OBVIOUS that the word is in that language. EG the word "zijn" is a Dutch word and should propably not be in the wiktionary.. The info is good :). As a new word is either from a given language because of the user settings (default EN) or because it came from a translation of a word, the language would be known. PS I can make a nice database relations diagram if anyone is interested.. PS2 If Wiktionary is interested in the glossary please contact me.
Hi, this is Ronline from the Romanian Wikipedia and the Romanian Wikitravel. How would it possible to start up a new version of Wiktionary in Romanian at ro.wiktionary.org, just like the French and Polish versions of the dictionary. I would really like to focus on the Wiktionary project in Romanian since it has huge potential! Ronline 14:31, 8 Apr 2004 (UTC)
I don't know whether you noticed when reverting my edits to Language considerations, but I moved the "Wiktionary:About LANGUAGE script" pages to "Wiktionary_Appendix:LANGUAGE script". This seems more appropriate since the only thing those pages do is giving a list of script symblos (usually an alphabet) for various languages and were indeed linked to by "Wiktionary_Appendix:Writing systems and alphabets". As far as I remember, the "About" pages were intended for providing guidelines on how to deal with peculiarities of languages that make it impossible to stick to WS:ELE. I see no point in insisting on a script-language split for those pages before they even contain any content. It makes it only more difficult to initiate discussions on conventions for languages other than English. Such a division should only be considered if these pages get overly busy (which we are far, far away from). Ncik 14:23, 7 January 2006 (UTC)
There are spellings of the same words in Romani with and without the stress mark: mamux/mamúx and kòkalo/kokalo. Should the stress mark deleted from words with the stress on the last syllable? Should the stress mark kept in words with the stress before the last syllable? --YukaSylvie (talk) 03:03, 13 February 2022 (UTC)