[
https://issues.apache.org/jira/browse/TIKA-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901335#action_12901335
]
Jan Høydahl commented on TIKA-490:
----------------------------------
Jukka,
Your idea for programmatic adding of profiles is good for some integration
scenarios.
My original intent with filing this issue however, was to support the case
where an (end) user or integrator needs to add support for a new langue on the
fly without programming.
For me as a Search engine Consultant I can then add say Sami Language support
to Solr extracting request handler by placing one property file and one
Language profile file on the classpath. With a constructor only this would
require code change to Solr.
So we can add constructor but please don't remove property file.
> 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
> Assignee: Chris A. Mattmann
> Fix For: 0.8
>
> Attachments: TIKA-490.janhoy.082310.patch,
> TIKA-490.janhoy.082310.patch, TIKA-490.Mattmann.082210.2.patch.txt,
> TIKA-490.Mattmann.082210.patch.txt, TIKA-490.patch, 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.
