alexchiri / i18n-binder Goto Github PK

Can the path in the first column be changed to be relative?  

For example, it currently writes the full path:

  C:\dev_files\project_A\i18n\filename-{locale}.properties

I edited the Excel file to remove the base directory, ending up with:

  i18n\filename-{locale}.properties

Seemed to work fine on writeProperties.  I don't know if the writeProperties 
uses the full path, but this would help team members take a file that was 
created on another computer and write the properties in their environment.

Thanks,
Jeff

Is the possible to add support of excel export with more than 65k rows to avoid 
such an exception? 

I think the current solution works with older version of Excel where only 65k 
rows is supported. Would it be possible to support later formats as well?

BUILD FAILED
c:\Development\DOCS\Siemens\SWE\translation\i18nBinder_0.1.12\build.xml:32: 
java.lang.IllegalArgumentException: Invalid row number (65536) outside all
ge (0..65535)
        at org.apache.poi.hssf.usermodel.HSSFRow.setRowNum(HSSFRow.java:232)
        at org.apache.poi.hssf.usermodel.HSSFRow.<init>(HSSFRow.java:86)
        at org.apache.poi.hssf.usermodel.HSSFRow.<init>(HSSFRow.java:70)
        at org.apache.poi.hssf.usermodel.HSSFSheet.createRow(HSSFSheet.java:213)
        at org.apache.poi.hssf.usermodel.HSSFSheet.createRow(HSSFSheet.java:79)
        at org.omnaest.i18nbinder.internal.XLSFile.store(XLSFile.java:138)
        at org.omnaest.i18nbinder.I18nBinder.createXLSFileFromFiles(I18nBinder.java:156)
        at org.omnaest.i18nbinder.I18nBinder.run(I18nBinder.java:103)
        at org.omnaest.i18nbinder.I18nBinder.execute(I18nBinder.java:73)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:392)
        at org.apache.tools.ant.Target.performTasks(Target.java:413)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
        at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
        at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
        at org.apache.tools.ant.Main.runBuild(Main.java:811)
        at org.apache.tools.ant.Main.startAnt(Main.java:217)
        at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
        at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)

What steps will reproduce the problem?
Using the i18nBinder with the following properties i18nBinder.properties : 

useJavaStyleUnicodeEscaping = true
fileEncoding = ISO-8859-1

There is a text in the Excel files which contains newlines. E.g.
"Firsts line with a special char í \n And the second line"

What is the expected output? What do you see instead?
I would escpect, that the String is translated to 
"Firsts line with a special char \u00ED \n And the second line"

But instead the newline is escapeded too:
"Firsts line with a special char \u00ED \\n And the second line"

This is not right, since newlines are supported by properties and by ISO-8859-1

What steps will reproduce the problem?
1. Checkout source code using linux
2. Execute `mvn install` in folder CommonUtils
3. Maven reports 1 test failure

What is the expected output? What do you see instead?

The expected value, taken from PropertyFile.properties, contains embedded DOS 
line endings (\r\n), while the generated file contains unix line endings (\n). 
Saving PropertyFile.properties using unix line endings fixes the problem. Unix 
line endings should work on Windows too, so I would suggest that as a fix.

What version of the product are you using? On what operating system?

SVN checkout of revision 40

Added possibility to read properties files with a non-default encoding.

What steps will reproduce the problem?
1. Export an Excel

What is the expected output?
Caffè

What do you see instead?
Caff\u00E8

What version of the product are you using? On what operating system?
0.1.16 (Maven)

Please provide any additional information below.
Having those strings in the Excel is confusing for translators. The task should 
output normal characters and then manage to convert them back to unicode 
escapes when importing back the Excel.

Added possibility to read properties files with a non-default encoding.

What steps will reproduce the problem?
1.  Have an i18n.xls file with more than one locale column, e.g. en_US and de_DE
2.  Delete the value for the first column, en_US
3.  After writing the properties file back, you can see that for the row 
modified that the columns are out of order, e.g. the de_DE value will show up 
in th en_US property file.

What is the expected output? What do you see instead?
I expect that the en_US file would no longer have that key/value pair

What version of the product are you using? On what operating system?

0.1.17 maven plugin, on windows 64 bit, office 2013


Please provide any additional information below.

What steps will reproduce the problem?
1. Create a XLS(X) output from non-UTF-8 input properties files

What is the expected output? What do you see instead?
When the original properties files are not UTF-8 encoded, they are not readed 
properly, they appear to be read as UTF-8 (so strange characters appears).

What version of the product are you using? On what operating system?
Bugs still exists on latest trunk version.


Please provide any additional information below.
Could be easily solved by using the ant "fileEncoding" parameter for reading 
(it is only used for writing at the moment).

Patch attached.

As depicted in a comment in issue 9 
(https://code.google.com/p/i18n-binder/issues/detail?id=9#c6), the 
configuration was not fixed.

By adding a property in build.xml and i18nBinder.properties, it solves the 
problem.

What steps will reproduce the problem?
1. have properties files with strings that end with or use '!' somewhere
2. createXLS
3.

What is the expected output? What do you see instead?
those strings should show up as well

What version of the product are you using? On what operating system?
0.1.2 on mac

Please provide any additional information below.
I think it is caused by the !, but I did not do thorough testing ... yet ... I 
can help with fixing the bug, but have not had time to set up the proj. yet.
I could provide a set of files, but they need to be treated confidentially.
You can contact me at [email protected] if you would like the samples.

Added possibility to read properties files with a non-default encoding.

I have attached an improved version of FacadeCreatorHelper.java:

1. java.util.Map is only imported if needed
2. generated Code for getters with replacement tokens should use Object-typed 
tokens instead if String

Maybe I can get committer permissions? :)

Regards, Stephan

Added possibility to read properties files with a non-default encoding.

What steps will reproduce the problem?
1.Create a properties file where the key has a space
2.run ant createXLSFile
3.open the XLS sheet. The key will be up to the space. The value is everything 
after the space.

What is the expected output? What do you see instead?
The space is escaped with a backslash. This should be supported.

What version of the product are you using? On what operating system?
Linux. Tried inside eclipse as well as stand alone ant.

Please provide any additional information below.