Comments (27)
This will need some additional work to translate extended properties and all of them in metadata viewer.
from iped.
Any idea about localization of configuration files comments? I will not translate them in config files. But the idea is to show them in tooltips in a future UI, so the tooltip should be translated. I would like to keep current english comments in config files too...
I think keeping the current comments in English is very important (for those who prefer editing the config files directly).
A simple solution would be having something like a "iped-config-messages_lang.txt" in localization folder, per each language, with config_file.values=comment:
ImageThumbsConfig.imgConvTimeout=Timeout (seconds) to wait for external image decoding (translated to another language).
ImageThumbsConfig.imgConvTimeoutPerMB=Additional time (seconds) per megabyte to be added to imgConvTimeout.
...
For English there won't be such file to avoid duplication.
Missing values could display English comment (or none).
That would work for property files, which cover most of the cases, right?
Well, this is a basic approach that probably can be improved...
from iped.
Thanks for warning @tc-wleite. I will fix when I return from vacation, thank you!
from iped.
Será lançada uma versão do iped 3.18 com a interface em português?
from iped.
@fcscoutinho, you just need to set "locale = pt-BR" in you LocalConfig.txt.
from iped.
Troquei para pt-BR e recebi a seguinte mensagem....
"You changed 'locale' in LocalConfig.txt but configured IPEDConfig.txt or conf/AdvancedConfig.txt in root folder! Please, restore those english config files to their defaults and set configuration in 'profiles/[lang]/default' folder!"
from iped.
Please, try a fresh "install" of Iped and just change 'locale' in LocalConfig.txt and do not change any other configuration file and say if that works.
from iped.
from iped.
Yes, because currently index fields change with language (category <-> categoria), you must not change locale after processing, a lot of things will stop working.
from iped.
from iped.
Yes, it is planned for version 4, because will break back compatibility. There are some details about filters and complex searches in portuguese, will need to be translated to english to work, probably updating leaf nodes of lucene query tree, after parsing search expressions.
from iped.
Will start working on this breaking change for 4.0. Category values and field names (name, size, type, path...) will be stored/indexed always in english. First 2 questions (not sure if easy/possible to implement):
- Search box must continue working if user searches for the localized category value, example for portuguese: "category:Documentos"? Or this is just desired?
- Search box must continue working if user searches for localized field names like "nome:windows"? Or this is just desired?
from iped.
PS: I will not reimplement lucene query text parser and they changed Query object to be immutable, also removing the clone() method. Yet not sure if it is possible to manually clone the whole query tree to perform the localization on leaf nodes...
from iped.
- Search box must continue working if user searches for the localized category value, example for portuguese: "category:Documentos"? Or this is just desired?
- Search box must continue working if user searches for localized field names like "nome:windows"? Or this is just desired?
I managed to get this working cloning the query tree with translated leaf nodes, actually was not difficult. Will try to finish all the details and push tomorrow.
from iped.
As part of this, profiles will not depend on language anymore. @fsicoli you configured some specific brazilian categories in RefineCategories.js script task in pt-BR profiles, they will be removed, we have some options:
- Remove all those categories because they could result in strange false positives for other countries
- Move them to a parent category "Brazilian Software"
- Run only if we are in pt-BR locale (I don't like very much the idea of different results just because a different UI language was chosen)
from iped.
I think about externalizing all localization files from jar files to a conf folder to easy the translation to other languages by users. Maybe keep just the default english bundles in jar files to keep the modules working independently without problems, but externalizing them would easy the translation a lot (users will see english values for keys, portuguese is not a good starting point to translate from). Any ideas?
from iped.
externalize english files and fallback to key names if not found? Not very good but should keep modules working alone...
from iped.
As part of this, profiles will not depend on language anymore. @fsicoli you configured some specific brazilian categories in RefineCategories.js script task in pt-BR profiles, they will be removed, we have some options:
- Remove all those categories because they could result in strange false positives for other countries
- Move them to a parent category "Brazilian Software"
- Run only if we are in pt-BR locale (I don't like very much the idea of different results just because a different UI language was chosen)
Just adding my two cents here, these categories include Brazilian IRPF (DEC/REC files), right?
I think they are useful in some cases, so I wouldn't remove them (option 1). Maybe leaving them commented out, so they can be enabled back, is another option...
I also don't like the option 3.
from iped.
Just adding my two cents here, these categories include Brazilian IRPF (DEC/REC files), right?
Yes!
I think they are useful in some cases, so I wouldn't remove them (option 1). Maybe leaving them commented out, so they can be enabled back, is another option...
I also don't like option 1, but it is an option :)
I also don't like the option 3.
Probably will go with option 2. Actually files are not removed from original categories when added to those specific ones, so false positives won't hurt too much. Thanks @tc-wleite for your valuable cents!
from iped.
I think about externalizing all localization files from jar files to a conf folder to easy the translation to other languages by users. Maybe keep just the default english bundles in jar files to keep the modules working independently without problems, but externalizing them would easy the translation a lot (users will see english values for keys, portuguese is not a good starting point to translate from). Any ideas?
@tc-wleite any thoughts on this?
from iped.
I think about externalizing all localization files from jar files to a conf folder to easy the translation to other languages by users. Maybe keep just the default english bundles in jar files to keep the modules working independently without problems, but externalizing them would easy the translation a lot (users will see english values for keys, portuguese is not a good starting point to translate from). Any ideas?
@tc-wleite any thoughts on this?
It seems an interesting idea, which would make translations to other languages easier.
It definitely makes sense to have the English version in a external file.
Not sure if keeping a bundled version would be really necessary...
from iped.
Not sure if keeping a bundled version would be really necessary...
Also not sure.
from iped.
@lfcnassif, I know this issue is closed, but, just to understand.
There where some regexes in RegexConfig.txt that were language specific (like CPF, CNPJ, CNH, BOLETO, TITULO_ELEITOR for pt-BR profile).
Will those be removed?
from iped.
No, my fault, I forgot them... Will add them back tomorrow, possibly with a BRAZIL prefix to make it clear they are country specific. Thanks for warning me!
from iped.
Any idea about localization of configuration files comments? I will not translate them in config files. But the idea is to show them in tooltips in a future UI, so the tooltip should be translated. I would like to keep current english comments in config files too...
from iped.
Thanks Wladimir, I thought something like that.
from iped.
Hi @lfcnassif!
Testing other stuff with master branch here, I noticed a possible problem related to this issue.
Using pt-BR locale, Folders and Scanned Documents categories count (in category tree panel) is always shown as 0.
Looking at the code, I *think* it may be related to the fact that SetCategoryTask
class uses the localized name of these categories, while other categories use a fixed name (in English), defined in CategoriesByTypeConfig.txt.
from iped.
Related Issues (20)
- Aborting ArrayIndexOutOfBoundsException from Lucene when creating reports with huge files HOT 12
- KnownMetCarveTask might miss some deleted known.met files
- Optimize KnownMetCarving to seek instead of skipping huge files
- WhatsApp parsing timeout can break parsing of other WA databases HOT 1
- New parser to decode Teams conversations HOT 6
- Metadata with dots not being indexed on opensearch HOT 6
- Item being extract three times HOT 15
- IllegalArgumentException: Inconsistency of field data structures across documents when generating reports from multicases HOT 2
- Password HOT 4
- Error on Linux Mint during build, during test pass: OCRParserTest Tika tesseract returned error code 1 HOT 5
- Possible incorrect association between WhatsApp accounts and chats when there are multiple accounts (in Windows) HOT 1
- Optimize UFDR evidences opening time HOT 17
- Fix typo in "HashDBLooupConfig.txt" file name HOT 2
- Any executable in the case root folder is being copied to the report destination folder HOT 2
- Export items to local case if enableAutomaticExportFiles and enableMinIO are both enabled HOT 1
- Falta de visualização de Progresso da indexação com --nogui HOT 1
- Problem in version 4.1.2 HOT 2
- Load Timeline chart data structures just when it becomes visible HOT 4
- Load and process map data structures just when it is shown.
- Max heap memory used by Analysis App can be greater than RAM causing UI crashes HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from iped.