[meta] items from https://github.com/ckan/ckan/wiki/Ideas:-new-feature-requests-&-ideas

Items from that page as of March 11th 2014 are inlined below.

We should probably import selectively.
### Suggestions:
- make the API multilanguage too, especially for the metadata - from Philipp Küng (@philippkueng)
- Provide a field during install(?) to enter a URL under which portal provider will offer the source code of their CKAN instance to fulfill requirements of AGPL, clause 13. (Marcus Dapp @digisus, 2013-06-28)
- Option for disabling avatars
- CUSTOMISABLE ORGANISATION LABEL/TERMINOLOGY: the ability to rename "Organisation" with your own word (label) - functionality of organisations (or whatever they were labelled) would stay the same. For an institutional repository (ie a single organisation in the usual sense) a different terminology would likely be more intuitive to our researchers i.e. in our use case the whole research institute is the 'Organisation', but we might like to use 'Research Team' or some other word(s) in place of the CKAN generic 'Organisation'.
- Parse an extended void file for gathering all dataset (meta) data instead of manual updates using forms. This feature would allow a provider to manually paste in a link to a void file once. CKAN would then import all recognized meta data into CKAN and automatically update this depending on the stated update frequency of the file. (Especially desired for the datahub.io)
- Provide a bit more help when looking at the resources in a dataset:
- Require names for resources.
- Require resource names within a dataset to be distinct.
- When creating a new resource, suggest a default name by munging the file name or last part of the URL path, e.g. "crime-stats-xml".
- Remove "extras" fields from Org creation screen. It's very obscure to need extra key-value pairs. If a particular field is needed in this instance, change the metadata schema and add it to the form. Org creators should not be inventing their own fields. At least hide it unless enabled in the config file.
- Create an OData connector for CKAN. Would be great if I can point the free Tableau Public to a CKAN-powered portal and do vizzes without being an R/Processing wizard (Tableau Public is like the Excel of Visualization).
- #35 - Integrate R processing/visualisation: e.g. somehow connecting to (or enabling r scripts stored alongside the data) to interact with the likes of http://www.rstudio.com/shiny
- Add support for CAS authentication - As a city, we really only want our city employees to have user accounts, which will be created by sysadmin. Then, we would use CAS to authenticate our users. No passwords would need to be stored in ckan. Members of the public would still be able to browse, search and download datasets.
- Add support for [DCAT-AP](https://joinup.ec.europa.eu/asset/dcat_application_profile/description DCAT-AP). DCAT-AP specification is based on the Data Catalogue vocabulary (DCAT) for describing public sector datasets in Europe and its basic use case is to enable cross-data portal search for data sets and make public sector data better searchable across borders and sectors
- Add a "powered by CKAN" image + text to footers, so it's easy to see what's powering the site, and link it to the CKAN site (maybe aggregating a list of CKAN instances, somewhere)

The issue collects multiple feature requests from the linked CKAN wiki, but names no implementation files, tests, or entry points. Start by selecting one request and locating its affected CKAN subsystem; done would require a separately scoped change with defined behavior and tests.

Written by the indexing model from the issue text.