[ 
https://issues.apache.org/jira/browse/TIKA-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Høydahl updated TIKA-490:
-----------------------------

    Attachment: TIKA-490.patch

Here is my first patch (against current trunk 987074) which adds a properties 
file for languages list, and initializes profiles in constructor. I also made 
the new initProfiles() public so that it is possible to programmatically 
re-load the profiles if you have changed the property file, without restarting 
the JavaVM.

I also changed the URL for ISO639 to a more complete version, and extracted 
some strings into constants.

Also added a JDK logger to add some output. Did not use log4j or slf4j because 
those would require new dependencies and hurt backwards drop-in compatibility. 
We now log what languages get initalized and from which property file, which 
will aid in debugging.

All existing tests PASS. No API changes are done which breaks backward 
compatibility.

It would be great if someone could test it and commit it in time for 0.8, as I 
suspect to use it with Solr with some custom language profiles.

> Support for adding language profiles dynamically
> ------------------------------------------------
>
>                 Key: TIKA-490
>                 URL: https://issues.apache.org/jira/browse/TIKA-490
>             Project: Tika
>          Issue Type: Improvement
>          Components: languageidentifier
>    Affects Versions: 0.7
>            Reporter: Jan Høydahl
>             Fix For: 0.8
>
>         Attachments: TIKA-490.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> 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.
> Suggested approach:
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to