-
Notifications
You must be signed in to change notification settings - Fork 10
20201126(목)_회의록
SoHyun Park edited this page Nov 27, 2020
·
1 revision
클라이언트에서 번역을 해서 서버에 보내기
내 언어와 무관하게 입력하는 내용을 번역해서 번역창에 띄운다. (언어감지해서)
예 ) 한국어 유저라도, 영어로 입력을 하면 번역창에는 한국어가 나온다.
(앱) 작성 중인 메시지에 대해 실시간으로 번역본이 보이게
(앱) 내가 쓴 메시지를 전송 후에는 → 원문만 보이게
(앱) 상대가 쓴 메시지는 내가 설정한 언어가 더 크게 보이기
ex) 내가 한국어 유저인데 상대도 한국어 유저이다 → 그래도 한국어 영어 둘다 보이지만, 한국어가 조금 더 크게
(웹) 내가 쓴 메시지 → 내가 쓴 원문이 왼쪽, 번역이 오른쪽
(웹) 상대가 쓴 메시지는 무조건 내 언어 왼쪽, 다른 언어가 오른쪽
[Web]
발표자: 강근우
- 기획 변경 (공개/비공개 방)
- 레디스로 디비 변경
- 소켓 & api 명세서
- 간략한 프론트, 백 디렉터리 구성
[iOS]
발표자: 김영렬
- 데모 시연
- MVVM 구조 설계, UI 디자인
- 전체적인 Scene Flow
- ViewModel, ViewController 구성도
- 서버 인스턴스가 하나면 마음대로...
- 당연히 현업에선 무조건 DB가 있음
- 실시간 번역과 관련해서, 실시간으로 나오는 거는 번역의 퀄리티보다는 유저가 느끼기에 번역이 되고 있구나를 느낄 수 있는 게 중요해서 저비용 api를 사용한다.
- 저비용은 하드웨어 리소스를 덜 잡아먹는 통계적 방식의 엔진을 사용. 최종 결과물은 (혹은 약간 멈춰서 보여줘야 하는 번역은) 고품질 번역을 띄우는 것으로 진행. (일정 시간 동안 입력이 없으면 고품질로 번역을 해준다던가)
- 실제로는 번역은 서버에서 돌고 있다. 그래도 우리 프로젝트 안에서는 그냥 클라이언트가 다 번역해서 보내는 게 좋다 (특히 방에서 2가지 언어만 사용한다고 가정하면 더욱 간단). 당연히 모든 언어가 들어오면 이건 서버가 하는 것이 맞음. 민식님은 무조건 서버에서 하는 게 맞다고 생각하심. (위의 의견은 종원님 의견)
- 아니면 굳이 클라이언트가 모든 걸 보내기 싫다면, 실시간 번역 느낌보다는 입력하고 번역이 잘 되고 있는지를 확인할 수 있는 버튼 같은 걸 만들어두어도 괜찮을 수 있다.
- 네이버 전체를 위한 디자인 시스템은 의미가 있을듯
- 파파고만을 위한 시스템은 고민이 된다
- 재사용을 정말 많이 해야 의미가 있다. 단발성 프로젝트는 고민이 될듯
- 인원이 늘면서 고민은 하고 계시다고 함. 색상, 프리미티브 타입들의 정의 정도는 하고 있음.
- 커버리지 100%는 라이브러리가 아니면 불가...
- api 테스트 정도만. 프론트가 호출해오는 것에 대한 테스트.
- 필요하다면 스냅샷 테스트 정도만!
- 최대한 동사로 끝나는 건 피하는 게 좋으나, 규모 있고 알려진 곳들에도 동사를 쓰는 경우가 간혹 있음.
- 아무리 생각해도 답이 없다면 동사도 무방^^
- Observable 의 경우 Trigger postfix를 사용하자, 나머지는 명시를 해주자
- Main Scheduler 에서 돌아가는 로직이 확실하다면 Unowned를 사용해도 무방하다
- 쫄리면 무조건 weak 써라❗️