Forums : Suggestions for Ohloh 2.0

Dear Open Hub Users,

We’re excited to announce that we will be moving the Open Hub Forum to https://community.blackduck.com/s/black-duck-open-hub. Beginning immediately, users can head over, register, get technical help and discuss issue pertinent to the Open Hub. Registered users can also subscribe to Open Hub announcements here.


On May 1, 2020, we will be freezing https://www.openhub.net/forums and users will not be able to create new discussions. If you have any questions and concerns, please email us at [email protected]

Feature to manually adjust the language for a project

It seems to me that no matter what amount of effort is taken to make Ohcount recognise languages, there will always be situations where Ohcount will get it wrong.

It also seems to me that Ohcount should not be expected to accommodate non-standard use of file extensions in cases where a clear standard or de-facto standard exists.

So, how can Ohloh handle such oddity cases?

I thought it would be a good idea to let project owners/managers edit file-extension mappings on a per-project basis.

This should also include an option to map to meta-data or ignore-this. For example, there seem to be quite a few projects with files that contain meta data generated by the build system but are in some cases confused for source code in some language.

I realise this sounds easier than it is to implement but it would seem to make more sense in the long term than requiring disambiguation code to be written for every single odd case.

trijezdci about 15 years ago
 

Hi trijezdci,

We've had this discussion before but never got around to it. An idea would be to allow a project to have a .code_info or .ohloh file in the root whereby project maintainers could specify how to manage their extensions & code layout.

For example, it would be interesting to specify where test code lives, etc...

The first step would be to enable the ohcount tool to accept a configuration file.

Jason Allen almost 15 years ago