error[E0277]: the trait bound `CowStr<'_>: From<&&String>` is not satisfied

[nduchaux]

Hello,

I have updated rust-i18n from 3.0.1 to 3.1.2.
My project does not compile anymore with the error message :
error[E0277]: the trait bound CowStr<'_>: From<&&String> is not satisfied

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait From<&&String> is not implemented for CowStr<'_>

let key = &self.my_string;
let translation = t!(key);

Am I doing something wrong now or the api changed in 3.1.2?

[nduchaux]

Updated my code to:

let key = self.my_string.as_str();
let translation = t!(key);

and it works. But I don't get why the old syntax was working and is not anymore.

[franz65]

I got the same error and tried to solve in the same way. Now those lines don't give me error anymore, unfortunately it's not enough because I have another problem. In my lib.rs I have these commands
use rust_i18n::{t, i18n}; rust_i18n::i18n!();

without calling rust_i18n::i18n!() I can't use the library, but now these command gives me always the error
the trait bound CowStr<'_>: From<&&String> is not satisfied

[a365344743s]

I got the same error and tried to solve in the same way. Now those lines don't give me error anymore, unfortunately it's not enough because I have another problem. In my lib.rs I have these commands use rust_i18n::{t, i18n}; rust_i18n::i18n!();

without calling rust_i18n::i18n!() I can't use the library, but now these command gives me always the error the trait bound CowStr<'_>: From<&&String> is not satisfied

me too

[huacnlee]

I'm sorry about this, this is looks like we recent changes not converted all case.

https://github.com/longbridgeapp/rust-i18n/blob/99ff77bd4631a79075d530ed0ccc6faeaeadb8ee/crates/support/src/cow_str.rs

In PR #73

But, I don't think we need to support CowStr<'_>: From<&&String>, it looks like not a right use way. As you see, the cow_str.rs are tried to cover some know case, but not have &&String. but by now I consider that we my not good to add this.

In your case here, I have some quesions:

1. Why there is a &&String type, sorry I did't saw the source type.
2. In I18n case by rust-i18n designed, we better to expect all keys better be a static string not a dynamic string, because dynamic string is hard to mantain that will make some missing translated), for example if there a enum key need to translate, I may write a match statement for each Enum member to have it own full translate key, not use t!(format!("my_enum.{}", ...)) like.

[nduchaux]

It's ok I don't need it. I just use .as_str() now. It was just strange that the API changed.

In my case, we have some static and some dynamic strings.
Regarding the dynamic strings, it is possible to NOT have a translation, that's perfectly intended.
For example,

let unit_key = format!("{}.Description", key);
let translation = t!(unit_key);
if !unit_key.eq(&translation) {
   // translation found, do something with it
}

In this example, it is ok because I just created the String and own it. But sometimes, this String is inside another Struct and I could't move it (because the struct needed it) so I used this &&String like I presented in my first example to avoid cloning the String.