On 2005-07-20 12:26, Gerard Meijssen wrote:
Entering data using SQL will be possible for those who have database access.
Ah, thanks, I did not know yet that this could be done from outside wihtout downloading the full database to do it locally.
As it is a relational database, the inclusion of a translation for "Dutch" in a language will imply that the User Interface of that language will use that translation in stead of "Dutch".
translation can be twofold: some data is native in one language which would required real translation mechanisms.
However, lots of data is in any kind of numerics or normalized form. Thus it's mainly a definition of native column headers or field type formats (e.g. date conversion from mm.dd.yyyy to yyyy-mm-dd).
Several projects have been described on Meta that make use of this eg http://meta.wikimedia.org/wiki/Using_Ultimate_Wiktionary_for_Commons Ultimate Wiktionary does this explicitly (see the ERD)
I never looked at those Wiktionary details. Thanks - I'll check later on. Maybe I should check for inclusions of my *ictionaries, such as Phictionary: Photographic terms http://home.arcor.de/objektive/Phictionary.html Bictionary: Bicycle terms http://www.fa-technik.adfc.de/Ratgeber/Bictionary/index.html
A dictionary is one of those examples where you want search and table options, although the sort requirement is less important.
It would be nice to have all the things you describe as spreadsheet like functionality, custom sort orders etc. We are however talking about a server side application. These kind of functionality require huge amounts of processing power and disk IO, I do not think this will prove to be practical.
I agree that search, sort etc. are server side - and those are huge task. However, google and other search engines show that you may list many found hits on one pages. It's just not in a table view yet.
I don't know about spreadsheet like operation. I guess there could be different client side editors (any kind based on some Java* ?) that could permit spreadsheet like operations, while the SQL interface might be the easiest choice. I guess it's more the question of providing or recommending the proper SQL tools and setup for this kind of work.
Merging data in one repository however is very much the goal.
Glad to hear.
I didn't understand this kind of info from http://meta.wikimedia.org/wiki/Wikidata
Thanks, Martin