Currently the Tika LanguageIdentifier loads language profiles thorugh a hardcoded static block in the java code.
It would be better to make this configurable, so you could add your own languages without recompiling.
Remove the static code block loading all languages. Instead look for a tika.languageidentification.properties file on classpath.
Now the user can simply make his/her own (additional) language profile files, put them on the classpath together with a properties file and off you go!
Also, once you make it configurable, there might be an issue of having the profiles as static members, as you will force the same behaviour for the whole VM. A static Map of Maps could solve this.
|Assignee||Chris A. Mattmann [ chrismattmann ]|
|Status||Open [ 1 ]||In Progress [ 3 ]|
[ Comment from Jan on the ML:
My rationale for the override part is as follows:
The default properties file will be embedded within tika-xx.jar
I assume most people are not keen to unpack and repack JARs to make a config change.
We COULD put a similar named properties file at another location, but then the user
needs to make sure that location is EARLIER in classpath than the JAR file.
In the case of e.g. Solr (Tomcat, Jetty..) it is not obvious how to ensure this,
and to avoid any confusion about class-loader peculiarities, it's more straight-forward
to look for an override file.
Take the Solr example. The user would then put the properties file along with
his new language profiles in a folder $SOLR_HOME/lib/org/apache/tika/language/
|Status||In Progress [ 3 ]||Resolved [ 5 ]|
|Resolution||Fixed [ 1 ]|
|Transition||Time In Source Status||Execution Times||Last Executer||Last Execution Date|
|10h 2m||1||Chris A. Mattmann||21/Aug/10 22:53|
|71d 7h 27m||1||Chris A. Mattmann||01/Nov/10 05:21|