bengbengbalabalabeng commented on issue #57:
URL: https://github.com/apache/fesod/issues/57#issuecomment-3507567244
Hi, I have a design proposal for internationalization (i18n) support,
focusing on reading and writing headers with `@ExcelProperty`. I'm also willing
to contribute a PR to implement it.
### Proposal
Introduce a new `MessageSource` interface within the Fesod, along with two
default implementations:
1. `ResourceBundleMessageSource`: Based on the JDK's native `ResourceBundle`.
2. `StaticMessageSource`: A simple Map-based implementation.
This approach allows Fesod's i18n functionality to be used standalone,
without dependencies on frameworks like Spring.
For projects that are integrated with frameworks like `Spring Boot` or
`Quarkus`, we can provide corresponding `MessageSource` implementations in
their respective extension modules (e.g., `fesod-spring`、`fesod-quarkus`) to
seamlessly integrate with the framework's own i18n ecosystem.
### API Usage Example
1. Define i18n keys:
```java
public class ExcelModelData {
@ExcelProperty(value = "{head.column.name}")
private String name;
@ExcelProperty(value = "{head.column.age}")
private String age;
// getters, setters...
}
```
2. Read/Write:
```java
// Supports .xlsx, .xls, .csv formats
File file = new File("/file.xlsx");
// Load resources from resources/i18n/messages_*.properties
MessageSource ms = new ResourceBundleMessageSource();
ms.addBasename("i18n/messages");
// Localize headers for write
FastExcel.write(file, ExcelModelData.class)
.localizedHead(ms, Locale.CHINA)
.sheet()
.doWrite(data());
// Localize headers for read
FastExcel.read(file)
.head(ExcelModelData.class)
// The locale parameter is optional and defaults to
Locale.getDefault()
.localizedHead(ms)
.sheet()
.doReadSync();
```
3. Nested Message Support:
```properties
head.column.common.required=(REQUIRED)
# Resolved to "Name (REQUIRED)"
head.column.name=Name {head.column.common.required}
head.column.age=Age
```
### About Locale
I've noticed that Fesod already has a `locale(Locale)` method, which is
primarily used for formatting dates and numbers.
The `Locale` parameter in my proposed `localizedHead(ms, locale)` method
would be intentionally separate from the existing `locale()`. The reason is
that the language of the header text (e.g., Chinese, English) and the regional
format for data content (e.g., using a comma vs. a period for decimal
separators) may need to be different. Decoupling them provides greater
flexibility, allowing users to control these two aspects of i18n independently.
---
What does everyone think of this approach?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
